Что такое порт ключ

Записки IT специалиста

Достаточно часто системные администраторы сталкиваются с дилеммой: необходимо иметь возможность подключиться к собственным системам из любой точки мира, но при этом не выставлять открытыми наружу служебные порты. Отчасти это решается использованием VPN, но такая возможность присутствует не всегда, а в некоторых ситуациях единственной возможностью может оказаться только прямое подключение к системе. Но есть и другой способ, называемый Port Knocking, дословно обозначающий «постучать в порт», но не просто постучать, а особым образом, после чего вы сможете получить доступ, стучите — и вам откроют.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

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

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

Кроме того, стучащийся клиент может находиться в публичной сети, за VPN-сервером или прокси, да даже за NAT провайдера, в этом случае доступ к сервису, хоть и кратковременно, могут получить все пользователи, находящиеся с ним на одном IP-адресе.

Также трафик может быть перехвачен и проанализирован, что позволит вычислить правильную последовательность «стука» и чем чаще вы будете использовать Port Knocking, тем быстрее можно будет это сделать.

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

Port Knocking с использованием портов

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

При реализации данного метода следует соблюдать правильную последовательность правил в цепочке INPUT межсетевого экрана и основным правилом, вокруг которого будет строиться наша система будет разрешение уже установленных и связанных соединений (ESTABLISHED, RELATED) и если вы настраивали роутер по нашей инструкции, то данное правило будет стоять вторым в цепочке, после «правила-пустышки» разрешающего доступ из локальной сети.

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

А пока добавим новое правило. На закладке General укажем: Chain — input, Protocol — tcp, Dst. Port — 7890.

На закладке Action добавим действия: Action — add src to address list, Address List — KNOCK-1, Timeout — 00:00:30

Данное правило при обращении к порту 7890 добавит адрес источника в список KNOCK-1 на 30 секунд, в течении этого времени мы должны успеть обратиться к следующему порту, чтобы получить доступ. Поэтому не следует указывать слишком высокие значения, на наш взгляд 30 секунд вполне достаточно для выполнения нужных команд в терминале, в ряде случаев можно незначительно увеличить таймаут.

Теперь добавим еще одно правило. Закладка General: Chain — input, Protocol — tcp, Dst. Port — 9870. Закладка Advanced: Src. Address List — KNOCK-1.

Закладка Action: Action — add src to address list, Address List — KNOCK-ACCEPT, Timeout — 00:01:00.

Данное правило добавит в лист KNOCK-ACCEPT адрес того источника, который обратится к порту 9870 и при этом находится в списке KNOCK-1, время жизни записи в новом листе — 1 минута, за это время мы должны будем установить соединение с устройством.

Тоже самое в терминале:

Оба этих правила следует расположить выше правила, разрешающего уже установленные соединения. Ниже этого правила добавим разрешающее для подключения к целевому порту, в нашем случае это будет порт Winbox — 8291.

На закладке General укажем: Chain — input, Protocol — tcp, Dst. Port — 8291, на Advanced: Src. Address List — KNOCK-ACCEPT, вкладку Action не трогаем, так как accept действие по умолчанию.

В терминале для этого выполните:

Данное правило следует расположить ниже разрешающего установленные и связанные подключения.

Теперь пару слов о том, как это работает. Первые два правила заполняют листы с адресом источника, чтобы попасть в последний — KNOCK-ACCEPT — нам нужно в течении 30 секунд обратиться к последовательно к портам 7890 и 9870. Затем в течении минуты мы должны подключиться к целевому порту, в нашем случае это Winbox. После чего все пакеты этого соединения пойдут по правилу, разрешающему уже установленные соединения. Таким образом по истечении минуты новых соединений установить не удастся, а уже установленные будут продолжать работать до отключения.

Что же, правила есть, теперь попробуем постучаться. В Linux для этого можно использовать команду netcat — nc, для того чтобы постучаться на TCP-порт используйте:

Где XXX.XXX.XXX.XXX — IP-адрес вашего роутера. Ключ -z указывает сканировать порт без посылки данных, ключ -w задает таймаут в 1 секунду.

Для UDP-портов используйте:

В Windows постучаться немного сложнее, из стандартных средств можно использовать PowerShell:

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

Другой вариант — использование утилиты tcping, которая проще и удобнее в использовании, но позволяет опять таки стучать только в TCP-порты:

Ключ -n указывает количество посылаемых пакетов, в нашем случае один.

Также существуют специальные утилиты, позволяющие автоматизировать этот процесс, например, PortKnock, которая умеет работать как с TCP, так и с UDP портами и может обращаться последовательно к 4 портам.

Подведем небольшие итоги, Port Knocking с использованием портов достаточно прост в реализации, позволяет строить цепочки с нужным количеством портов и времени обращения к ним, но также имеет ряд недостатков. Прежде всего это ограниченность возможностей Windows, а ситуации бывают разные и не всегда есть время и возможности искать дополнительное ПО и качать его. Также близко расположенные порты без особых проблем можно простучать сканером.

Мы провели небольшой эксперимент, простая утилита Advanced Port Scanner без проблем простучала последовательности 7890-9870 и более сложную 7890-9870-8790, но не смог справиться с 17890-9870. Поэтому не используйте близко расположенные порты и устанавливайте минимальное время действия адресов в списках.

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

Port Knocking с использованием ICMP

Данный вариант отличается от классического тем, что вместо определенных портов мы будем использовать ICMP-пакеты различного размера. Это проще сделать стандартными средствами ОС и труднее поддается анализу при перехвате трафика, так как не столь бросается в глаза.

Несмотря на стандартный размер MTU в 1500 байт, это значение может быть уменьшено при использовании VLAN, VPN и т.д., поэтому мы не советуем использовать пакеты размером более 1000 байт, также учтите размер заголовков ICMP-пакета в 28 байт.

Просто выберите два (или более) произвольных числа до 1000, которые и будут вашими ключами для Port Knocking, в нашем случае это будут 250 и 209. Точно также, как и в предыдущем способе правила будут строиться относительно разрешения для уже установленных соединений.

Нам снова понадобится создать два правила для добавления адреса источника в соответствующие листы. В первом правиле укажем на General: Chain — input, Protocol — icmp, а на Advanced: Packet Size — 278 (250 + 28) — размер нашего первого пакета, на Action: Action — add src to address list, Address List — KNOCK-1, Timeout — 00:00:30.

Во втором зададим следующие значения: General: Chain — input, Protocol — icmp, Advanced: Src. Address List — KNOCK-1, Packet Size — 237 (209 + 28) — размер второго пакета, на Action: Action — add src to address list, Address List — KNOCK-ACCEPT, Timeout — 00:01:00.

Либо выполним в терминале:

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

Чтобы постучаться таким образом из Linux выполним:

Где ключ -s задает размер пакета (без учета заголовка), а ключ -с количество посылаемых пакетов, в нашем случае один.

В Windows синтаксис будет немного иной:

Здесь за размер пакета отвечает ключ -l, а за количество пакетов -n.

Принцип работы не отличается от предыдущего метода, получив ICMP-пакет размером в 250 байт адрес источника будет занесен в первый список. Затем в течении 30 секунд мы должны прислать второй пакет размером в 209 байт, в этом случае адрес будет занесен в список KNOCK-ACCEPT и в течении минуты с устройством можно будет установить соединение.

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

Дополнительные материалы:

Mikrotik

The Dude

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

USB-ключ безопасности: Что это такое и зачем он нужен?

Электронный ключ USB для защиты вашей информации и вашего ПК: Что это такое?

Когда дело доходит до защиты вашей информации, вы никогда не будете в полной безопасности. Хотя использование надежных паролей и программной двухфакторной аутентификации (2FA), безусловно является отличным началом. Вы можете еще больше укрепить свою онлайн-безопасность с помощью аппаратного ключа безопасности. Кроме того, их легко использовать как на личных, так и на служебных устройствах и учетных записях.

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

Что такое USB-ключ безопасности?

Физически USB-ключ безопасности (также называемый ключом U2F) — это тип аппаратной защиты, который напоминает USB-накопитель и подключается к одному из USB-портов вашего компьютера. На практике ключ безопасности — это физическое устройство безопасности с полностью уникальной идентификацией. Он содержит небольшой чип со всеми протоколами безопасности и кодом, который позволяет ему подключаться к серверам и проверять вашу личность. Он используется для того, чтобы убедиться, что вы действительно получаете доступ к сайту или услуге.

USB-ключ безопасности что это

Некоторые ключи безопасности даже имеют встроенный NFC или Bluetooth, что делает их идеальными для использования с новыми смартфонами Android и iOS. Ключи работают с такими браузерами, как Google Chrome, а также с веб-сервисами, такими как Gmail, Facebook, Dropbox, 1Password, Twitter, GitHub, Microsoft и многими другими.

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

Какие есть способы обезопасить свой компьютер?

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

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

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

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

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

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

Как работают электронные ключи защиты?

Электронные ключи безопасности — это еще один способ проверить на сервере, с которым вы пытаетесь связаться, что вы являетесь тем, кем себя называете. Ключи поддерживают универсальный стандарт с открытым исходным кодом под названием FIDO U2F , который был разработан Google и Yubico для физических токенов аутентификации.

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

USB-ключ безопасности

Установить и использовать электронный ключ также довольно просто. После того, как вы подключили устройства и онлайн-аккаунты, на которых хотите использовать ключ безопасности все, что вам нужно сделать на этом этапе — это подключить ключ, когда вы хотите получить доступ к устройству или сайту, и нажать сенсорную кнопку.

Кому следует использовать электронный ключ защиты?

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

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

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

Недостатки использования USB-ключа безопасности

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

лучшие ключи безопасности usb что это такое и как выбрать

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

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

Другие особенности, которые следует учитывать при покупке USB-ключа безопасности

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

Совместимость устройства и учетной записи: не все аппаратные ключи одинаковые. Некоторые подключаются к компьютеру через USB-A или USB-C, а другие поддерживают только порты Apple Lightning. Новые варианты могут даже поддерживать Bluetooth и NFC, что делает их совместимыми со смартфонами. Убедитесь, что выбранный вами ключ будет работать со всеми устройствами, на которых вы хотите его использовать, от macOS и Windows до Android и iOS.

Долговечность: поскольку ключ безопасности — это то, что вы потенциально можете использовать каждый день, очень важно, чтобы он имел прочную конструкцию из высококачественных материалов. Металлические разъемы, которые подключаются к разъемам USB-порта вашего устройства, должны быть достаточно прочными, чтобы выдерживать тысячи применений. Лучшие ключи безопасности выдерживают падение (или падение на него чего-либо), а также водонепроницаемы.

Лучшие USB ключи безопасности

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

Лучший ключ безопасности: Yubico YubiKey 5 NFC

Yubico — это имя, которому доверяют в мире ключей безопасности, поскольку оно помогло разработать стандарт FIDO U2F вместе с Google. YubiKey 5 NFC использует как NFC и разъем USB-A, и является идеальным выбором для получения авторизовались на своих интернет — услуг и счетов, а также ваши MacOS компьютеры, Android устройств, а также iPhone 7 или более новые модели. Он поддерживает множество стандартов безопасности, включая FIDO U2F, FIDO2, Yubico OTP, OATH-HOTP, Open PGP и смарт-карту. Ключ устойчив к воде, взлому и раздавливанию.

Yubico YubiKey 5 NFC лучшие ключи безопасности

Yubico — YubiKey 5 NFC — двухфакторная аутентификация USB и ключ безопасности NFC, подходит для портов USB-A и работает с поддерживаемыми мобильными устройствами NFC — защитите свои учетные записи в Интернете с помощью не только пароля
Получите максимальную связь и безопасность для ваших компьютеров, мобильных устройств, совместимых веб-сайтов и служб.

Лучший бюджетный выбор: электронный ключ Thetis FIDO U2F

Вам не нужно тратить много денег, чтобы получить респектабельный ключ безопасности. Thetis FIDO U2F предлагает лучшую отдачу от вложенных средств. Ключ работает как в браузерах Chrome, так и в Opera в операционных системах MacOS, Windows и Linux. Он пропускает варианты подключения Bluetooth и NFC в пользу порта USB-A. У ключа Thetis есть поворотный механизм, который защищает USB-порт, когда он не используется.

Ключ безопасности FIDO U2F, Thetis [алюминиевый складной дизайн] Универсальная двухфакторная аутентификация USB (тип A) для дополнительной защиты в Windows, Linux,Mac OS, Gmail, Facebook, Dropbox, SalesForce, GitHub
Подключайтесь к своим устройствам и онлайн-аккаунтам и защищайте их, не тратя при этом целое состояние. Работает с системами Windows, macOS и Linux.

Комплект ключей безопасности Google Titan

Вместе с Yubico, Google помог разработать стандарт FIDO U2F, на который полагаются эти устройства, так что это еще один хороший выбор. Пакет Google Titan Key Bundle включает в себя один ключ Bluetooth и один ключ USB-A, поэтому вы можете подключаться к компьютерам и мобильным устройствам, а также к совместимым веб-службам.

USB-ключ безопасности что это и какой лучше выбрать

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

Электронные ключи — это простой и относительно недорогой способ сохранить важную информацию в Интернете. Хотя они могут быть излишними для обычного человека, уровень безопасности, который они предлагают, делает их полезными для всех, кто имеет дело с защищенной информацией, особенно в общедоступном Wi-Fi-соединении. Их также могут использовать знаменитости и известные люди. Также не теряйте свой электронный ключ безопасности.

Ключ HASP. Как он работает и взаимодействует с программами 1С?

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

Аппаратная защита реализуется очень просто. В свободный USB-порт компьютера ставится специальный ключ, который похож на флэшку. Вот только флэшкой такое устройство не является! Изначально кажется, что это обычная флэшкарта с записанной на неё информацией. Но попробуйте установить устройство в порт компьютера и зайти на него через обычный проводник для того, чтобы удалить там какие-то файлики.

Вы удивитесь, но никакой флэшки в системе не появляется! В чём же дело? Всё дело в том, что аппаратный ключ от 1С – это отдельное устройство, работающее по технологии HASP. Эта технология далеко не новая и применяется не только в программных продуктах 1С. Давайте узнаем о ней побольше!

Что такое HASP-ключ?

Аббревиатура HASP расшифровывается как Hardware Against Software Piracy. Прямой перевод фразы выглядит примерно так “Оборудование Против Пиратства Программного Обеспечения”. Мы имеем дело со специальным устройством, которое при подключении к компьютеру позволяет лицензировать необходимую программу.

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

Программно-аппаратные комплексы защиты чаще называют аппаратными ключами защиты. Именно такой аппаратный ключик и дают нам к любому программному продукту 1С. Они, кстати говоря, не случайно отличаются по цвету, но об этом мы расскажем как-нибудь в другой раз.

Аппаратные способы защиты основаны на том, что в компьютер вставляется специальное физическое защитное устройство. Оноопределяется системой как специальное устройство, но не как флэшка. Ждать, что HASP-ключ системой распознается как флэшка это тоже самое, что ожидать от адаптера Bluetooth от мышки определения как флэхи! Поэтому, не стоит думать, что такой ключ представляет собой именно карту памяти со служебной информацией.

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

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

Кстати, важно отметить, что технология HASP – мультиплатформенная. А значит, ключи аппаратной защиты будут работать и в Windows, и в UNIX-системах, и в Apple.

Как устроен ключ аппаратной защиты?

Хорошо, если HASP – ключ не является флэшкой, то что это тогда такое с аппаратной точки зрения? Если разобрать такой ключ, то внутренности и правда будут похожи на карту памяти. Но на деле, микросхемы только внешне похожи и полупроводниковая память обычно визуально напоминает полупроводниковый процессор.

Внутри такого устройства есть маленькая микросхема. Она размещена на плате из текстолита и есть ещё парочка вспомогательных деталей – диоды и перемычки.

Основой работы ключей типа HASP является специальная микросхема, которая называется ASIC (Application Specific Integrated Circuit). Эти микросхемы делаются на заказ по конкретному техническому заданию разработчика и изготавливаются всего лишь несколькими компаниями. На территории России этим вопросом занимается компания Alladin. Каждая микросхема имеет уникальный для каждого ключа алгоритм работы. Это означает, что даже в рамках одной серии программ используются разные чипы, которые могут на аппаратном уровне давать разные ответы. Для чего это делается, в общем-то, понятно. Нужно как-то исключить возможность изготовления аналогичной микросхемы, чтобы исключить нелегальное копирование или доступ к информации.

У каждого ключа HASP имеется уникальный опознавательный номер, или идентификатор (ID-number). Такой идентификатор присваивается электронному ключу в процессе изготовления и записать туда новый невозможно. Это гарантирует его защиту от повторного внесения. Можно использовать данные с ключа как код для шифра. Записывать зашифрованную информацию на диске компьютера и давать к ней вполне свободный доступ, но не допускать её расшифровки без ключа шифрования. Подобрать код шифровая хоть в теории и возможно, но задача эта настолько трудоемкая, что просто невозможно это реализовать на практике. Ну а по уровню защиты и работы с зашифрованной информацией – это как пароль в игре подобрать.

– По бесплатному телефону 8 (800) 600-32-31 или +7 (495) 139-09-60

– Оставьте заявку через наш сайт или через раздел контакты

Принцип защиты строится на том, что защищенная программа опрашивает подключенный к компьютеру ключ HASP и сверяет ответ с ожидаемым. Если HASP возвращает правильный ответ, то ключ к программе подходит. Если нет, то и нет. Логика работы чертовски тут похожа на механический. Не так давно мы разбирались в принципе работы полупроводниковой памяти и выяснили, что правильно построенная аппаратная цепочка может использоваться как логическая и операторы в полупроводником транзисторе тоже существуют на аппаратном уровне. В итоге ничто не мешает “прогнать” электрон по предполагаемой схеме, которая построена подобно лабиринту для крысы. Выполнение такой схемы даст правильный ответ на выходе. Его и ожидает увидеть компьютер, а программа просканирует этот результат и сопоставит с заложенным.

Физическая подделка такого чипа довольно затруднительна. Ведь следует изготовить точно такой же чип! Даже изготовление стандартного чипа – штука довольно трудоемкая.

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

Для активации лицензии тут необходимо по сети передать слепок системы с ключом активации в Sentinel EMS. После проверки ключа активации Sentinel EMS выдаст лицензию. Этот файлик запишется специальным образом на диск и тоже будет недоступен для штатной обработки. Уровень безопасности программных лицензий не сильно уступает уровню аппаратных ключей.

Как можно использовать HASP?

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

Использование ключа как ключа. Управлять доступом к программам самого разного типа по описанным выше алгоритмам и технологиям
Присваивать каждой программе уникальный серийный номер. Ключ сделает это без дополнительных примочек. Просто сканирование обработанного алгоритма позволяет опознать, что вставлен такой-то аппаратный ключ защиты и присвоить конкретному ключу виртуальный номер
Организовать аренду программы, управляя удаленно доступом к программе в нужный период по конкретному аппаратному ключу или настроить демки
хранить в ключе пароли, части программы или непосредственно код расшифровки кода основного программного продукта
Использовать ключ для 100% идентификации программы при работе со службой поддержки или запускать удаленно нужные алгоритмы обслуживания, уникальные для каждого клиента

Насколько надежен HASP ключ?

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

Как такой ключ используется в 1С-ке?

Поскольку разговор мы с вами начали именно про использование HASP-ключа в программах 1С, отметим парочку особенностей применительно именно к этому случаю.

Во-первых, ключи для 1С-ки отличаются по цвету. Цвет определяет вариант программы, для которой будет применяться такая защита. Бывают они фиолетовые, зеленые, красные и синие.

Ключ синего цвета – это ключ для одного пользователя и использоваться должен на локальной машине. Такой ключ обычно поставляется с продуктом для одного пользователя
Ключ красного цвета – виден всем компьютерам сети и может быть на разное количество пользователей. Это сетевой ключ
Фиолетовый ключ – это ключ для 32-битного сервера и поставляется с лицензией на сервер
Зеленый ключ – тоже серверный и нужен для работы 64 битного сервера, хотя может работать и с 32-битным

Во-вторых, ключи в случае 1С не имеют сопоставление программного кода с алгоритмом ключа или, говоря по-русски, любой ключ может открыть любую программу. Но нужно помнить, что каждый ключ регистрируется на определенного пользователя. А как мы помним, помимо аппаратной защиты на ключ ещё можно внести и набор служебных данных. В случае 1С – это специальный идентификационный номер, который привязывается к одному клиенту и если вы запустили с этим ключом другую программу, то возникнут сложности и лицензия потеряется. Поэтому, хоть ключи является по сути универсальным, его надо использовать ТОЛЬКО с предполагаемым программным обеспечением.

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

Памятка пользователям ssh

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

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

управление ключами
копирование файлов через ssh
Проброс потоков ввода/вывода
Монтирование удалённой FS через ssh
Удалённое исполнение кода
Алиасы и опции для подключений в .ssh/config
Опции по-умолчанию
Проброс X-сервера
ssh в качестве socks-proxy
Проброс портов — прямой и обратный
Реверс-сокс-прокси
туннелирование L2/L3 трафика
Проброс агента авторизации
Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)

Управление ключами

Теория в нескольких словах: ssh может авторизоваться не по паролю, а по ключу. Ключ состоит из открытой и закрытой части. Открытая кладётся в домашний каталог пользователя, «которым» заходят на сервер, закрытая — в домашний каталог пользователя, который идёт на удалённый сервер. Половинки сравниваются (я утрирую) и если всё ок — пускают. Важно: авторизуется не только клиент на сервере, но и сервер по отношению к клиенту (то есть у сервера есть свой собственный ключ). Главной особенностью ключа по сравнению с паролем является то, что его нельзя «украсть», взломав сервер — ключ не передаётся с клиента на сервер, а во время авторизации клиент доказывает серверу, что владеет ключом (та самая криптографическая магия).

Генерация ключа

Свой ключ можно сгенерировать с помощью команды ssh-keygen. Если не задать параметры, то он сохранит всё так, как надо.

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

Сменить пароль на ключ можно с помощью команды ssh-keygen -p.

Структура ключа

/.ssh/id_rsa.pub — открытый ключ. Его копируют на сервера, куда нужно получить доступ.

/.ssh/id_rsa — закрытый ключ. Его нельзя никому показывать. Если вы в письмо/чат скопипастите его вместо pub, то нужно генерировать новый ключ. (Я не шучу, примерно 10% людей, которых просишь дать ssh-ключ постят id_rsa, причём из этих десяти процентов мужского пола 100%).

Копирование ключа на сервер

/.ssh/authorized_keys и положить туда открытый ключ, то можно будет заходить без пароля. Обратите внимание, права на файл не должны давать возможность писать в этот файл посторонним пользователям, иначе ssh его не примет. В ключе последнее поле — user@machine. Оно не имеет никакого отношения к авторизации и служит только для удобства определения где чей ключ. Заметим, это поле может быть поменяно (или даже удалено) без нарушения структуры ключа.

Если вы знаете пароль пользователя, то процесс можно упростить. Команда ssh-copy-id user@server позволяет скопировать ключ не редактируя файлы вручную.

Замечание: Старые руководства по ssh упоминают про authorized_keys2. Причина: была первая версия ssh, потом стала вторая (текущая), для неё сделали свой набор конфигов, всех это очень утомило, и вторая версия уже давным давно переключилась на версии без всяких «2». То есть всегда authorized_keys и не думать о разных версиях.

Если у вас ssh на нестандартном порту, то ssh-copy-id требует особого ухищрения при работе: ssh-copy-id ‘-p 443 user@server’ (внимание на кавычки).

Ключ сервера

/.ssh/known_hosts. Узнать, где какой ключ нельзя (ибо несекьюрно).

Если ключ сервера поменялся (например, сервер переустановили), ssh вопит от подделке ключа. Обратите внимание, если сервер не трогали, а ssh вопит, значит вы не на тот сервер ломитесь (например, в сети появился ещё один компьютер с тем же IP, особо этим страдают всякие локальные сети с 192.168.1.1, которых в мире несколько миллионов). Сценарий «злобной man in the middle атаки» маловероятен, чаще просто ошибка с IP, хотя если «всё хорошо», а ключ поменялся — это повод поднять уровень паранойи на пару уровней (а если у вас авторизация по ключу, а сервер вдруг запросил пароль — то паранойю можно включать на 100% и пароль не вводить).

Удалить известный ключ сервера можно командой ssh-keygen -R server. При этом нужно удалить ещё и ключ IP (они хранятся раздельно): ssh-keygen -R 127.0.0.1.

Ключ сервера хранится в /etc/ssh/ssh_host_rsa_key и /etc/ssh/ssh_host_rsa_key.pub. Их можно:
а) скопировать со старого сервера на новый.
б) сгенерировать с помощью ssh-keygen. Пароля при этом задавать не надо (т.е. пустой). Ключ с паролем ssh-сервер использовать не сможет.

Заметим, если вы сервера клонируете (например, в виртуалках), то ssh-ключи сервера нужно обязательно перегенерировать.

Старые ключи из know_hosts при этом лучше убрать, иначе ssh будет ругаться на duplicate key.

Копирование файлов

Передача файлов на сервер иногда может утомлять. Помимо возни с sftp и прочими странными вещами, ssh предоставляет нам команду scp, которая осуществляет копирование файла через ssh-сессию.

scp path/myfile user@8.8.8.8:/full/path/to/new/location/

Обратно тоже можно:
scp user@8.8.8.8:/full/path/to/file /path/to/put/here

Fish warning: Не смотря на то, что mc умеет делать соединение по ssh, копировать большие файлы будет очень мучительно, т.к. fish (модуль mc для работы с ssh как с виртуальной fs) работает очень медленно. 100-200кб — предел, дальше начинается испытание терпения. (Я вспомнил свою очень раннюю молодость, когда не зная про scp, я копировал

5Гб через fish в mc, заняло это чуть больше 12 часов на FastEthernet).

Возможность копировать здорово. Но хочется так, чтобы «сохранить как» — и сразу на сервер. И чтобы в графическом режиме копировать не из специальной программы, а из любой, привычной.

sshfs

Теория: модуль fuse позволяет «экспортировать» запросы к файловой системе из ядра обратно в userspace к соответствующей программе. Это позволяет легко реализовывать «псевдофайловые системы». Например, мы можем предоставить доступ к удалённой файловой системе через ssh так, что все локальные приложения (за малым исключением) не будут ничего подозревать.

Собственно, исключение: O_DIRECT не поддерживается, увы (это проблема не sshfs, это проблема fuse вообще).

Использование: установить пакет sshfs (сам притащит за собой fuse).

Собственно, пример моего скрипта, который монтирует desunote.ru (размещающийся у меня на домашнем комьютере — с него в этой статье показываются картинки) на мой ноут:

Делаем файл +x, вызываем, идём в любое приложение, говорим сохранить и видим:

Параметры sshfs, которые могут оказаться важными: -o reconnect (говорит пытаться пересоединиться вместо ошибок).

Если вы много работаете с данными от рута, то можно (нужно) сделать idmap:

-o idmap=user. Работает она следующим образом: если мы коннектимся как пользователь pupkin@server, а локально работаем как пользователь vasiliy, то мы говорим «считать, что файлы pupkin, это файлы vasiliy». ну или «root», если мы коннектимся как root.

В моём случае idmap не нужен, так как имена пользователей (локальное и удалённое) совпадают.

Заметим, комфортно работать получается только если у нас есть ssh-ключик (см. начало статьи), если нет — авторизация по паролю выбешивает на 2-3 подключение.

Отключить обратно можно командой fusermount -u /path, однако, если соединение залипло (например, нет сети), то можно/нужно делать это из-под рута: sudo umount -f /path.

Удалённое исполнение кода

ssh может выполнить команду на удалённом сервере и тут же закрыть соединение. Простейший пример:

ssh user@server ls /etc/

Выведет нам содержимое /etc/ на server, при этом у нас будет локальная командная строка.

Некоторые приложения хотят иметь управляющий терминал. Их следует запускать с опцией -t:
ssh user@server -t remove_command

Кстати, мы можем сделать что-то такого вида:
ssh user@server cat /some/file|awk ‘‘ |local_app

Это нас приводит следующей фиче:

Проброс stdin/out

Допустим, мы хотим сделать запрос к программе удалённо, а потом её вывод поместить в локальный файл

ssh user@8.8.8.8 command >my_file

Допустим, мы хотим локальный вывод положить удалённо

mycommand |scp — user@8.8.8.8:/path/remote_file

Усложним пример — мы можем прокидывать файлы с сервера на сервер: Делаем цепочку, чтобы положить stdin на 10.1.1.2, который нам не доступен снаружи:

mycommand | ssh user@8.8.8.8 «scp — user@10.1.1.2:/path/to/file»

Есть и вот такой головоломный приём использования pipe’а (любезно подсказали в комментариях в жж):

tar -c * | ssh user@server «cd && tar -x»

Tar запаковывает файлы по маске локально, пишет их в stdout, откуда их читает ssh, передаёт в stdin на удалённом сервере, где их cd игнорирует (не читает stdin), а tar — читает и распаковывает. Так сказать, scp для бедных.

Алиасы

Скажу честно, до последнего времени не знал и не использовал. Оказались очень удобными.

В более-менее крупной компании часто оказывается, что имена серверов выглядят так: spb-MX-i3.extrt.int.company.net. И пользователь там не равен локальному. То есть логиниться надо так: ssh ivanov_i@spb-MX-i3.extrt.int.company.net. Каждый раз печатать — туннельных синдромов не напасёшься. В малых компаниях проблема обратная — никто не думает о DNS, и обращение на сервер выглядит так: ssh root@192.168.1.4. Короче, но всё равно напрягает. Ещё большая драма, если у нас есть нестандартный порт, и, например, первая версия ssh (привет цискам). Тогда всё выглядит так: ssh -1 -p 334 vv_pupkin@spb-MX-i4.extrt.int.company.net. Удавиться. Про драму с scp даже рассказывать не хочется.

Можно прописать общесистемные alias’ы на IP (/etc/hosts), но это кривоватый выход (и пользователя и опции всё равно печатать). Есть путь короче.

/.ssh/config позволяет задать параметры подключения, в том числе специальные для серверов, что самое важное, для каждого сервера своё. Вот пример конфига:

Все доступные для использования опции можно увидеть в man ssh_config (не путать с sshd_config).

Опции по умолчанию

По подсказке UUSER: вы можете указать настройки соединения по умолчанию с помощью конструкции Host *, т.е., например:

То же самое можно сделать и в /etc/ssh/ssh_config (не путать с /etc/ssh/sshd_config), но это требует прав рута и распространяется на всех пользователей.

Проброс X-сервера

Собственно, немножко я проспойлерил эту часть в примере конфига выше. ForwardX11 — это как раз оно.

Теория: Графические приложения в юникс обычно используют X-сервер (wayland в пути, но всё ещё не готов). Это означает, что приложение запускается и подключается к X-серверу для рисования. Иными словами, если у вас есть голый сервер без гуя и есть локальный x-сервер (в котором вы работаете), то вы можете дать возможность приложениям с сервера рисовать у вас на рабочем столе. Обычно подключение к удалённом X-серверу — не самая безопасная и тривиальная вещь. SSH позволяет упростить этот процесс и сделать его совсем безопасным. А возможность жать трафик позволяет ещё и обойтись меньшим трафиком (т.е. уменьшить утилизацию канала, то есть уменьшить ping (точнее, latency), то есть уменьшить лаги).

Ключики: -X — проброс X-сервера. -Y проброс авторизации.

Достаточно просто запомнить комбинацию ssh -XYC user@SERVER.
В примере выше (названия компании вымышленные) я подключаюсь к серверу ооо-рога-и-копыта.рф не просто так, а с целью получить доступ к windows-серверу. Безопасность microsoft при работе в сети мы все хорошо знаем, так что выставлять наружу голый RDP неуютно. Вместо этого мы подключаемся к серверу по ssh, а дальше запускаем там команду rdesktop:
ssh ric
rdesktop -k en-us 192.168.1.1 -g 1900×1200

и чудо, окошко логина в windows на нашем рабочем столе. Заметим, тщательно зашифрованное и неотличимое от обычного ssh-трафика.

Socks-proxy

Когда я оказываюсь в очередной гостинице (кафе, конференции), то местный wifi чаще всего оказывается ужасным — закрытые порты, неизвестно какой уровень безопасности. Да и доверия к чужим точкам доступа не особо много (это не паранойя, я вполне наблюдал как уводят пароли и куки с помощью банального ноутбука, раздающего 3G всем желающим с названием близлежащей кафешки (и пишущего интересное в процессе)).

Особые проблемы доставляют закрытые порты. То джаббер прикроют, то IMAP, то ещё что-нибудь.

Обычный VPN (pptp, l2tp, openvpn) в таких ситуациях не работает — его просто не пропускают. Экспериментально известно, что 443ий порт чаще всего оставляют, причём в режиме CONNECT, то есть пропускают «как есть» (обычный http могут ещё прозрачно на сквид завернуть).

Решением служит socks-proxy режим работы ssh. Его принцип: ssh-клиент подключается к серверу и слушает локально. Получив запрос, он отправляет его (через открытое соединение) на сервер, сервер устанавливает соединение согласно запросу и все данные передаёт обратно ssh-клиенту. А тот отвечает обратившемуся. Для работы нужно сказать приложениям «использовать socks-proxy». И указать IP-адрес прокси. В случае с ssh это чаще всего localhost (так вы не отдадите свой канал чужим людям).

Подключение в режиме sock-proxy выглядит так:

В силу того, что чужие wifi чаще всего не только фиговые, но и лагливые, то бывает неплохо включить опцию -C (сжимать трафик). Получается почти что opera turbo (только картинки не жмёт). В реальном сёрфинге по http жмёт примерно в 2-3 раза (читай — если вам выпало несчастье в 64кбит, то вы будете мегабайтные страницы открывать не по две минуты, а секунд за 40. Фигово, но всё ж лучше). Но главное: никаких украденных кук и подслушанных сессий.

Я не зря сказал про закрытые порты. 22ой порт закрывают ровно так же, как «не нужный» порт джаббера. Решение — повесить сервер на 443-й порт. Снимать с 22 не стоит, иногда бывают системы с DPI (deep packet inspection), которые ваш «псевдо-ssl» не пустят.

Вот так выглядит мой конфиг:

/etc/ssh/sshd_config:
(фрагмент)
Port 22
Port 443

/.ssh/config с ноутбука, который описывает vpn

(обратите внимание на «ленивую» форму записи localhost — 127.1, это вполне себе законный метод написать 127.0.0.1)

Проброс портов

Мы переходим к крайне сложной для понимания части функционала SSH, позволяющей осуществлять головоломные операции по туннелированию TCP «из сервера» и «на сервер».

Для понимания ситуации все примеры ниже будут ссылаться на вот эту схему:

Комментарии: Две серые сети. Первая сеть напоминает типичную офисную сеть (NAT), вторая — «гейтвей», то есть сервер с белым интерфейсом и серым, смотрящим в свою собственную приватную сеть. В дальнейших рассуждениях мы полагаем, что «наш» ноутбук — А, а «сервер» — Б.

Задача: у нас локально запущено приложение, нам нужно дать возможность другому пользователю (за пределами нашей сети) посмотреть на него.

Решение: проброс локального порта (127.0.0.1:80) на публично доступный адрес. Допустим, наш «публично доступный» Б занял 80ый порт чем-то полезным, так что пробрасывать мы будем на нестандартный порт (8080).

Итоговая конфигурация: запросы на 8.8.8.8:8080 будут попадать на localhost ноутбука А.

ssh -R 127.1:80:8.8.8.8:8080 user@8.8.8.8

Опция -R позволяет перенаправлять с удалённого (Remote) сервера порт на свой (локальный).
Важно: если мы хотим использовать адрес 8.8.8.8, то нам нужно разрешить GatewayPorts в настройках сервера Б.
Задача. На сервере «Б» слушает некий демон (допустим, sql-сервер). Наше приложение не совместимо с сервером (другая битность, ОС, злой админ, запрещающий и накладывающий лимиты и т.д.). Мы хотим локально получить доступ к удалённому localhost’у.

Итоговая конфигурация: запросы на localhost:3333 на ‘A’ должны обслуживаться демоном на localhost:3128 ‘Б’.

ssh -L 127.1:3333:127.1:3128 user@8.8.8.8

Опция -L позволяет локальные обращения (Local) направлять на удалённый сервер.

Задача: На сервере «Б» на сером интерфейсе слушает некий сервис и мы хотим дать возможность коллеге (192.168.0.3) посмотреть на это приложение.

Итоговая конфигурация: запросы на наш серый IP-адрес (192.168.0.2) попадают на серый интерфейс сервера Б.

ssh -L 192.168.0.2:8080:10.1.1.1:80 user@8.8.8.8

Вложенные туннели

Разумеется, туннели можно перенаправлять.

Усложним задачу: теперь нам хочется показать коллеге приложение, запущенное на localhost на сервере с адресом 10.1.1.2 (на 80ом порту).

Решение сложно:
ssh -L 192.168.0.2:8080:127.1:9999 user@8.8.8.8 ssh -L 127.1:9999:127.1:80 user2@10.1.1.2

Что происходит? Мы говорим ssh перенаправлять локальные запросы с нашего адреса на localhost сервера Б и сразу после подключения запустить ssh (то есть клиента ssh) на сервере Б с опцией слушать на localhost и передавать запросы на сервер 10.1.1.2 (куда клиент и должен подключиться). Порт 9999 выбран произвольно, главное, чтобы совпадал в первом вызове и во втором.

Реверс-сокс-прокси

Если предыдущий пример вам показался простым и очевидным, то попробуйте догадаться, что сделает этот пример:
ssh -D 8080 -R 127.1:8080:127.1:8080 user@8.8.8.8 ssh -R 127.1:8080:127.1:8080 user@10.1.1.2

Если вы офицер безопасности, задача которого запретить использование интернета на сервере 10.1.1.2, то можете начинать выдёргивать волосы на попе, ибо эта команда организует доступ в интернет для сервера 10.1.1.2 посредством сокс-прокси, запущенного на компьютере «А». Трафик полностью зашифрован и неотличим от любого другого трафика SSH. А исходящий трафик с компьютера с точки зрения сети «192.168.0/24» не отличим от обычного трафика компьютера А.

Туннелирование

Если к этому моменту попа отдела безопасности не сияет лысиной, а ssh всё ещё не внесён в список врагов безопасности номер один, вот вам окончательный убийца всего и вся: туннелирование IP или даже ethernet. В самых радикальных случаях это позволяет туннелировать dhcp, заниматься удалённым arp-спуфингом, делать wake up on lan и прочие безобразия второго уровня.

(сам я увы, таким не пользовался).

Легко понять, что в таких условиях невозможно никаким DPI (deep packet inspection) отловить подобные туннели — либо ssh разрешён (читай — делай что хочешь), либо ssh запрещён (и можно смело из такой компании идиотов увольняться не ощущая ни малейшего сожаления).

Проброс авторизации

Если вы думаете, что на этом всё, то…… впрочем, в отличие от автора, у которого «снизу» ещё не написано, читатель заранее видит, что там снизу много букв и интриги не получается.

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

Для начала о простом пробросе авторизации.

Допустим, мы хотим подключиться к серверу 10.1.1.2, который готов принять наш ключ. Но копировать его на 8.8.8.8 мы не хотим, ибо там проходной двор и половина людей имеет sudo и может шариться по чужим каталогам. Компромиссным вариантом было бы иметь «другой» ssh-ключ, который бы авторизовывал user@8.8.8.8 на 10.1.1.2, но если мы не хотим пускать кого попало с 8.8.8.8 на 10.1.1.2, то это не вариант (тем паче, что ключ могут не только поюзать, но и скопировать себе «на чёрный день»).

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

Вызов выглядит так:

ssh -A user@8.8.8.8 ssh user2@10.1.1.2

Удалённый ssh-клиент (на 8.8.8.8) может доказать 10.1.1.2, что мы это мы только если мы к этому серверу подключены и дали ssh-клиенту доступ к своему агенту авторизации (но не ключу!).

В большинстве случаев это прокатывает.

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

Есть ещё более могучий метод — он превращает ssh в простой pipe (в смысле, «трубу») через которую насквозь мы осуществляем работу с удалённым сервером.

Главным достоинством этого метода является полная независимость от доверенности промежуточного сервера. Он может использовать поддельный ssh-сервер, логгировать все байты и все действия, перехватывать любые данные и подделывать их как хочет — взаимодействие идёт между «итоговым» сервером и клиентом. Если данные оконечного сервера подделаны, то подпись не сойдётся. Если данные не подделаны, то сессия устанавливается в защищённом режиме, так что перехватывать нечего.

Эту клёвую настройку я не знал, и раскопал её redrampage.

Настройка завязана на две возможности ssh: опцию -W (превращающую ssh в «трубу») и опцию конфига ProxyCommand (опции командной строки, вроде бы нет), которая говорит «запустить программу и присосаться к её stdin/out». Опции эти появились недавно, так что пользователи centos в пролёте.

Выглядит это так (циферки для картинки выше):

Ну а подключение тривиально: ssh raep .

Повторю важную мысль: сервер 8.8.8.8 не может перехватить или подделать трафик, воспользоваться агентом авторизации пользователя или иным образом изменить трафик. Запретить — да, может. Но если разрешил — пропустит через себя без расшифровки или модификации. Для работы конфигурации нужно иметь свой открытый ключ в authorized_keys как для user@8.8.8.8, так и в user2@10.1.1.2

Разумеется, подключение можно оснащать всеми прочими фенечками — прокидыванием портов, копированием файлов, сокс-прокси, L2-туннелями, туннелированием X-сервера и т.д.

Финал

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