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

Обновлено: 06.07.2024

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

Содержание работы

Файлы: 1 файл

Оформление КР_Протоколы.doc

Список использованных источников…. . . 19

Для организации взаимодействия клиентской и серверной частей программ удаленного управления существуют протоколы удаленного доступа и управления, например Telnet, Rlogin, SSH, RDP, VNC и другие. Некоторые из этих протоколов открыты, их описание и использование доступно широкой публике. Некоторые программы удаленного управления, например Radmin, используют для своей работы собственные закрытые протоколы. Протоколы удаленного доступа управляют передачей данных по глобальным сетям. То, какой протокол удаленного доступа могут использовать клиенты, зависит от используемых клиентами и серверами удаленного доступа операционной системы и протоколов локальной сети.

Собственно для цели передачи команд администрирования и вывода экрана используются протоколы удалённого администрирования: RDP, VNC, X11, Telnet, Rlogin, RFB, ARD, ICA, ALP и собственные закрытые протоколы. Для шифрования трафика в программах удалённого администрирования используются протоколы SSH, SSL, TLS и др. В своей работе я рассмотрю некоторые из них.

1 ПРОТОКОЛ TELNET

Telnet как протокол описан в RFC-854 (май, 1983 год). Его авторы J.Postel и J.Reynolds во введении к документу определили назначение telnet так: "Назначение TELNET-протокола -- дать общее описание, насколько это только возможно, двунаправленного, восьмибитового взаимодействия, главной целью которого является обеспечение стандартного метода взаимодействия терминального устройства и терминал-ориентированного процесса. При этом этот протокол может быть использован и для организации взаимодействий "терминал-терминал" (связь) и "процесс-процесс" (распределенные вычисления)."

Под telnet понимают триаду, состоящую из:

telnet-интерфейса пользователя;
telnetd-процесса;
TELNET-протокола.

Эта триада обеспечивает описание и реализацию сетевого терминала для доступа к ресурсам удаленного компьютера.

Основными реализациями протокола Telnet являются:

Клиенты: telnet (Unix), PuTTY, telnet.exe (Windows),z/Scope Express VT,AbsoluteTelnet
Серверы: telnetd, MS Telnet.

В настоящее время из-за своей небезопасности протокол Telnet считается устаревшим и вместо него используется протокол SSH.

2 ПРОТОКОЛ RLOGIN

Rlogin появился в 4.2BSD и был предназначен для захода удаленным терминалом между Unix хостами. Поэтому Rlogin проще, чем Telnet, так как он не требует определение параметров, которые для одной и той же операционной системы известны заранее и для клиента, и для сервера. Через несколько лет Rlogin был перенесен на не-Unix системы. RFC 1282 [Kantor 1991] содержит спецификацию протокола Rlogin. Однако, как и в случае с RFC посвященным RIP (Routing Information Protocol), он был написан после того, как Rlogin уже использовался в течении нескольких лет.

Основными реализациями протоколами Rlogin являются:

Клиенты: Rlogin, PuTTY
Серверы: Rlogin

В настоящее время из-за своей небезопасности протокол Rlogin считается устаревшим и вместо него используется протокол SSH.

3 ПРОТОКОЛ SSH

Первая версия протокола, SSH-1, была разработана в 1995 году исследователем Тату Улёненом из Технологического университета Хельсинки, Финляндия. SSH-1 был написан для обеспечения большей конфиденциальности, чем протоколы rlogin, telnet и rsh. В 1996 году была разработана более безопасная версия протокола, SSH-2, несовместимая с SSH-1. Протокол приобрел ещё большую популярность, и к 2000 году у него было около двух миллионов пользователей. В настоящее время под термином «SSH» обычно подразумевается именно SSH-2, т.к. первая версия протокола ввиду существенных недостатков сейчас практически не применяется. В 2006 году протокол был утвержден рабочей группой IETF в качестве Интернет-стандарта.

Распространены две реализации SSH: собственническая коммерческая и бесплатная свободная. Свободная реализация называется OpenSSH. К 2006 году 80 % компьютеров сети Интернет использовало именно OpenSSH. Собственническая реализация разрабатывается организацией SSH Inc., она бесплатна для некоммерческого использования. Эти реализации содержат практически одинаковый набор команд.

Протокол SSH-2, в отличие от протокола telnet, устойчив к атакам прослушивания трафика («снифинг»), но неустойчив к атакам «человек посередине». Протокол SSH-2 также устойчив к атакам путем присоединения посредине (англ. session hijacking) - невозможно включиться в или перехватить уже установленную сессию.

Для предотвращения атак «человек посередине» при подключении к хосту, ключ которого ещё не известен клиенту, клиентское ПО показывает пользователю "слепок ключа" (key fingerprint). Рекомендуется тщательно проверять показываемый клиентским ПО "слепок ключа" (key fingerprint) со слепком ключа сервера, желательно полученным по надежным каналам связи или лично.

Поддержка SSH реализована во всех UNIX-подобных системах, и на большинстве из них в числе стандартных утилит присутствуют клиент и сервер ssh. Существует множество реализаций SSH-клиентов и для не-UNIX ОС. Большую популярность протокол получил после широкого развития анализаторов трафика и способов нарушения работы локальных сетей, как альтернативное небезопасному протоколу Telnet решение для управления важными узлами.

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

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

Основными реализациями протоколами SSH являются:

SSH-серверы

BSD: OpenSSH
Linux: dropbear, lsh-server, openssh-server, ssh
Windows: freeSSHd, copssh, WinSSHD, KpyM Telnet/SSH Server, MobaSSH, OpenSSH через Cygwin

SSH-клиенты и оболочки

GNU/Linux, *BSD: kdessh, lsh-client, openssh-client, putty, ssh
MS Windows и Windows NT: PuTTY, SecureCRT, ShellGuard, Axessh, ZOC, SSHWindows, ProSSHD, XShell
MS Windows Mobile: PocketPuTTy, mToken, sshCE, PocketTTY, OpenSSH, PocketConsole
Mac OS: NiftyTelnet SSH
Symbian OS: PuTTY
Java: MindTerm, AppGate Security Server
J2ME: MidpSSH
iPhone: i-SSH, ssh (в комплекте с Terminal)
Android: connectBot
Blackberry: BBSSH
MAEMO 5: OpenSSH

4 ПРОТОКОЛ SLIP

SLIP (Serial Line Internet Protocol) — устаревший сетевой протокол канального уровня эталонной сетевой модели OSI для доступа к сетям стека TCP/IP через низкоскоростные линии связи путём простой инкапсуляции IP-пакетов. Используются коммутируемые соединения через последовательные порты для соединений клиент-сервер типа точка-точка. В настоящее время вместо него используют более совершенный протокол PPP.

Протокол SLIP (Serial Line Internet Protocol) является старым стандартом удаленного доступа, используемым, в основном, серверами удаленного доступа на платформе UNIX. Клиенты удаленного доступа, использующие Windows Server, поддерживают SLIP и могут подключаться к любому серверу удаленного доступа, также поддерживающему стандарт SLIP. Это позволяет клиентам Windows NT версии 3.5 и последующих версий подключаться к множеству существующих UNIX-серверов.SLIP был разработан в начале 80-х компанией 3COM. Протокол начал быстро распространяться после включения в ОС Berkeley Unix 4.2 Риком Адамсом (Rick Adams) в 1984, так как благодаря ему стало возможным подключение к Интернет через последовательный COM-порт, имевшийся на большинстве компьютеров. Ввиду своей простоты сейчас используется в микроконтроллерах
Недостатки

Нет возможности обмениваться адресной информацией — необходимость предустановки IP-адресов.
Отсутствие индикации типа инкапсулируемого протокола — возможно использование только IP.
Не предусмотрена коррекция ошибок — необходимо выполнять на верхних уровнях, рекомендуется использовать протокол TCP.
Высокая избыточность — из-за использования стартовых и стоповых битов при асинхронной передаче (+20 %), передачи в каждом SLIP-кадре полного IP-заголовка (+20 байт) и полных заголовков верхних уровней, байт-стаффинга.
В некоторых реализациях протокола максимальный размер кадра ограничен 1006 байтами для достижения обратной совместимости с реализацией в Berkeley Unix.

PPP (англ. Point-to-Point Protocol) — двухточечный протокол канального уровня сетевой модели OSI. Обычно используется для установления прямой связи между двумя узлами сети, причем он может обеспечить аутентификацию соединения, шифрование (с использованием ECP, RFC 1968) и сжатие данных. Используется на многих типах физических сетей: нуль-модемный кабель, телефонная линия, сотовая связь и т. д.

Часто встречаются подвиды протокола PPP, такие как Point-to-Point Protocol over Ethernet (PPPoE), используемый для подключения по Ethernet, и иногда через DSL; и Point-to-Point Protocol over ATM (PPPoA), который используется для подключения по ATM Adaptation Layer 5 (AAL5), который является основной альтернативой PPPoE для DSL.

PPP представляет собой целое семейство протоколов: протокол управления линией связи (LCP), протокол управления сетью (NCP), протоколы аутентификации (PAP, CHAP), многоканальный протокол PPP (MLPPP).

PPP протокол был разработан на основе HDLC (High-Level Data Link Control- бит-ориентированный протокол канального уровня сетевой модели OSI, разработанный ISO) и дополнен некоторыми возможностями, которые до этого встречались только в проприетарных протоколах.

Link Control Protocol (LCP) обеспечивает автоматическую настройку интерфейсов на каждом конце (например, установка размера пакетов) и опционально проводит аутентификацию. Протокол LCP работает поверх PPP, то есть начальная PPP связь должна быть до работы LCP.

RFC 1994 описывает Challenge-handshake authentication protocol (CHAP), который является предпочтительным для соединений с провайдерами. Уже устаревший Password authentication protocol (PAP) всё еще иногда используется.Другим вариантом аутентификации через PPP является Extensible Authentication Protocol (EAP).

После того, как соединение было установлено, поверх него может быть настроена дополнительная сеть. Обычно используется Internet Protocol Control Protocol (IPCP), хотя Internetwork Packet Exchange Control Protocol (IPXCP) и AppleTalk Control Protocol (ATCP) были когда-то популярны. Internet Protocol Version 6 Control Protocol (IPv6CP) получит большее распространение в будущем, когда IPv6 заменит IPv4 как основной протокол сетевого уровня.

PPP позволяет работать нескольким протоколам сетевого уровня на одном канале связи. Другими словами, внутри одного PPP-соединения могут передаваться потоки данных различных сетевых протоколов (IP, Novell IPX и т. д.), а также данные протоколов канального уровня локальной сети. Для каждого сетевого протокола используется Network Control Protocol (NCP) который его конфигурирует (согласовывает некоторые параметры протокола).

Так как в PPP входит LCP протокол, то можно управлять следующими LCP параметрами:

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

Удаленный компьютер (удаленный хост) — сервер, физически размещенный на некотором расстоянии от клиента и доступ к которому (для клиентов) возможен только по сети.

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

Терминалы

С середины 1970-х до середины 1980-х годов вся работа за компьютером выполнялась через специальные устройства ввода-вывода — терминалы. С помощью терминалов пользователи подключались к серверу (мэйнфрейму) и использовали его системные ресурсы для решения прикладных задач.

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

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

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

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

В зависимости от них различают:

текстовые терминалы;
графические терминалы;
«интеллектуальные» терминалы.

Текстовые терминалы

Потоки данных между терминалом и сервером представляют ASCII-символы. Специальные символы (или последовательности символов) представляют команды управления сервером и ответы сервера. Существуют и служебные команды, управляющие выводом (перевод строки, полужирный/наклонный текст, звуковой сигнал и т.п.) и сеансом связи (согласование версий протокола и др.).

Текстовые терминалы отличаются минимальными требованиями к полосе пропускания сети. Это позволяет дистанционно управлять удаленными серверами (например, в сети Интернет), используя медленные коммутируемые соединения (модемную связь через порт RS-232C).

«Продвинутые» модели текстовых терминалов поддерживают т.н. «блочный режим», основанный на буферизации вводимых данных. Символы, которые были получены с клавиатуры, сохраняются в памяти терминала (и их можно отредактировать встроенным строковым редактором) до нажатия клавиши ввода/передачи (Enter или что-то подобное). Таким образом, серверу передается целая строка (блок символов).

«Тупые» (dumb) терминалы

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

Графические терминалы

Для графических терминалов применяются два типа дисплеев:

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

Текстовый режим работы также поддерживается графическими терминалами, но реализован иначе — внутри основного протокола.

«Интеллектуальные» терминалы

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

В приведенной трактовке типичным примером интеллектуального терминала является бездисковая рабочая станция — компьютер, у которого отсутствует жесткий диск (а зачастую и сменные накопители). Загрузка операционной системы и приложений для такого компьютера выполняется по сети.

«Тонкие клиенты»

Протоколы удаленного управления

telnet
Служба удаленного управления telnet (Teletype Network) ) — одна из самых старых сетевых технологий Internet (первая спецификация — RFC 158 от 19.05.1971 г.). Текущая спецификация telnet — RFC 854/STD 8 – Telnet Protocol Specification. По умолчанию сервер telnet принимает входящие подключения на 23-ий порт TCP (см. Сетевые сервисы).

Протокол telnet изначально разрабатывался для использования в гетерогенных сетях. В его основе — концепция сетевого виртуального терминала (Network Virtual Terminal, NVT) — механизма абстрагирования от специфики ввода/вывода различных аппаратных и программных платформ. Так, например, в UNIX в качестве символа перехода на другую строку используется LF (код 13), в то время как в MS-DOS и Windows — пара символов CR-LF (коды 10 и 13). Сетевой виртуальный терминал NVT предлагает использование унифицированного набора символов, который используется для преобразования кодов клиента и сервера.

Хотя в сессии telnet выделяют клиентскую и серверную сторону, протокол является симметричным и обе стороны взаимодействуют через NVT, обмениваясь данными двух типов:

Прикладными данными (т.е. данными, которые идут от пользователя к серверному приложению и обратно);
Опциями протокола telnet, служащими для уяснения возможностей и предпочтений сторон.

Все значения октетов прикладных данных кроме \377 (десятичное 255) передаются по транспорту как есть. Октет \377 передаётся последовательностью \377\377 из двух октетов. Это связано с тем, что октет \377 используется для кодирования опций протокола.

Telnet поддерживает четыре режима передачи:

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

rlogin

Впервые появившаяся в составе 4.2BSD UNIX, программа rlogin (и остальные r-команды) одно время была исключительно популярной в этой среде. В качестве средства терминального доступа rlogin очень похожа на telnet, но из-за тесной интеграции с ОС нашла ограниченное применение в других системах.

В rlogin отсутствуют многие опции, свойственные telnet, в частности режим согласования параметров между клиентом и сервером. Однако rlogin предусматривает хотя бы минимальные средства защиты на основе доверительных отношений между хостами: на сервере rlogin в специальных системных файлах (обычно /etc/hosts.equiv и $HOME/.rhosts) администратор может перечислить компьютеры, доступ с которых к данному серверу будет разрешен без пароля.

Пользователи других компьютеров (не перечисленных в этих файлах) могут войти на сервер лишь после ввода пароля (который как и в telnet передается в открытом виде). Но, доверительные отношения между хостами тоже не панацея, и могут устанавливаться лишь в изолированных сетях. Дело в том, что такие техники несанкционированного доступа, как подмена IP-адресов (IP-spoofing) и доменных имен (DNS-spoofing), делают r-сервисы в Интернет незащищенными. Поэтому современные дистрибутивы UNIX-подобных ОС включают не фактические r-команды, а замещающие ссылки на их SSH-аналоги: scp, sftp и др.(см. man rlogin в Ubuntu, выводящий руководство по OpenSSH).

SSH (Secure Shell)

Согласно Указу Президента Российской Федерации № 334 от 03.04.95 физическим лицам и организациям, включая государственные, частные и акционерные, запрещена эксплуатация систем криптографии, не прошедших сертификации в ФАПСИ. А SSH (а иже с ним PGP) является именно такой системой.

Не стоит думать, что нам пытаются запретить защищать конфиденциальную информацию: организации не только могут, но и обязаны защищать важную информацию. Только для этого они должны применять сертифицированные средства. Применяя свободное, но несертифицированное ПО на основе ssh, SSL, PGP и т.п. следует помнить, что его использование чревато разбирательством со стороны спецслужб.

Сервис SSH использует по умолчанию порт 22 и объединяет протоколы трех уровней:

Практически все задачи управления UNIX могут выполняться в текстовом режиме, однако администраторы нередко предпочитают графический интерфейс, как более удобный. Вдобавок, некоторыми приложениями UNIX можно управлять только в графической среде. Программное обеспечение X-server, отвечающее за вывод графической информации, имеется для множества платформ, включая DOS, Windows, Macintosh, UNIX и т.д.

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

При подключении к серверу UNIX (на котором запускаются клиенты X11) аутентификация может осуществляться двумя методами: через терминальные утилиты (telnet, rlogin и т. п.) и через менеджер дисплеев X (X Display Manager, xdm). В первом варианте передачи пароля в открытом виде можно избежать, применяя вместо telnet и rlogin уже упоминавшиеся программы ssh и OTP. В случае X Display Manager пароли по умолчанию передаются в открытом виде. Поэтому при удаленном управлении сервером UNIX по общедоступным сетям xdm пользоваться не стоит.

Очень осторожно администраторы должны подходить к вопросу использования сервера UNIX в качестве сервера X (т. е., говоря понятным языком, к запуску графической оболочки X11 на сервере UNIX). X Window System устроена так, что пользователь может со своей машины запустить клиента X на удаленном сервере X и перехватывать на нем ввод/вывод информации. В результате злоумышленник получает возможность считывать конфиденциальную информацию с сервера X, включая пароли, вводимые пользователем на сервере X (хотя эмулятор терминала xterm позволяет блокировать перехват пароля, этой возможностью редко кто пользуется).

На серверах X применяются две схемы аутентификации клиентов: по имени хоста и с помощью «магических плюшек» (MIT-MAGIC-COOKIE-1). При аутентификации по имени хоста на сервере X создаются системные файлы, где перечисляются хосты, откуда разрешено запускать клиентские программы X на данном сервере X. Но подобную защиту никак не назовешь достаточной, так как с помощью подмены IP-адресов или доменных имен злоумышленник может провести атаку на X11.

При использовании же схемы «магических плюшек» (их поддержка встроена в протокол XDMCP, на основе которого функционирует X Display Manager) аутентификация осуществляется на основании учетных записей пользователей. Чтобы иметь право запустить клиента на сервере X, пользователь в своем домашнем каталоге машины-клиента X11 должен иметь системный файл с записанным секретным кодом сервера X. Этот секретный код и называется магической плюшкой. Беда только в том, что плюшка передается по сети в открытом виде, поэтому данный метод также вряд ли можно считать безопасным.

В X Window System 11 Release 5 добавлены еще две схемы (XDM-AUTHORIZATION-1 и SUN-DES-1), напоминающие схему MIT-MAGIC-COOKIE-1, но использующие алгоритм шифрования DES. Однако из-за экспортных ограничений такие схемы в комплект поставки X Window System не включают. Исходя из вышеприведенных соображений, запускать серверное ПО X11 на сервере UNIX можно лишь в том случае, когда запрещен доступ клиентов X11 с других компьютеров.

Remote Desktop Protocol

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

Для соединения инструмент Remote Desktop использует LAN, виртуальную частную сеть (VPN) или интернет-соединение. Работа удаленного рабочего стола сильно зависит от скорости установленного соединения.

Remote Desktop поддерживает работу в двух режимах:

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

Переадресация звуков позволяет компьютеру-клиенту воспроизводить звуки, которые генерируются на компьютере-сервере. При проигрывании звуков Remote Desktop также учитывает пропускную способность полосы частот. Вместо того чтобы перегружать соединение звуковым сигналом при изменении пропускной способности, Remote Desktop снижает качество звука.

Remote Desktop-сервер и Remote Desktop-клиент пользуются общим буфером. Это позволяет им свободно обмениваться информацией.

Веб-технологии удаленного управления

Всемирная Паутина (World Wide Web) оказывает все большее влияние на средства управления сетевой средой. Уже сейчас многие маршрутизаторы, коммутаторы, сетевые принтеры допускают управление через web-браузеры.

Но список этот далеко не исчерпывается ими и Web вторгается и в сферу управления сетевыми ОС.

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

Протокол PPTP

Протокол PPTP определяет реализацию криптозащищенного туннеля на канальном уровне OSI. В свое время операционные системы Win NT/2000 поддерживали этот протокол. Сегодня его поддерживают многие межсетевые экраны и VPN. PPTP отлично работает с протоколами Ip, IPX или NETBEUI. Пакеты, которые передаются в сессии PPTP, имеют следующую структуру (рис.1).

Универсальность этого протокола отлично подходит для локальных сетей, где реализованы протоколы IPX или NetBEUI. Для таких сетей уже невозможно использовать IPSec или SSL.

Архитектура протокола PPTP видна на рис.2. Схема туннелирования при прямом соединении компьютера удаленного пользователя к Интернету видно на рис.3.

Протокол L2TP и L2f

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

Протокол L2TP использует для передачи данных UDP. На рис.5 видна структура пакета для передачи по туннелю L2TP.

Протокол L2TP использует схемы, где туннель создается между сервером удаленного доступа провайдера и маршрутизатором локальной сети. Также протокол может открывать несколько туннелей, каждый из которых может использоваться для конкретного приложения. Протокол PPTP не имеет такой возможности. В роли сервера удаленного доступа провайдера должен быть концентратор доступа LAC, который создает клиентскую часть протокола L2TL и реализует удаленному пользователю доступ к локальной сети через интернет. Схема показана на рис.6.

Соединение реализуется в 3 этапа:

Протокол L2TP работает поверх любого транспорта с коммуникацией пакетов. Также L2TP не определяет конкретные методы криптозащиты.

Протоколы защиты на сетевом уровне

протокол IPSec

Главная задача протокола IPSec это реализация безопасности передачи информации по сетям IP. IPSec гарантирует:

Протокол IPSec имеет следующие компоненты:

Ядро протокола IPSec составляет 3 протокола: AH (протокол аутентифицирующего заголовка), ESP (протокол инкапсулирующей защиты) и IKE (протокол согласования параметров управления ключами и виртуального канала). Архитектура стека протоколов IPSec показана на рис.7.

Протокол АН ответственен только за реализацию аутентификации и целостности информации, в то время как протокол ESP и реализует функции АН и алгоритмы шифрования. Протоколы IKE, AH и ESP работают следующим образом.

С помощью протокола IKE создается логическое соединение между 2 точками, которое имеет название безопасная ассоциация SA. При реализации такого алгоритма, происходит аутентификация конечных точек линии, и выбираются параметры защиты информации. В рамках созданной безопасной ассоциации SA стартует протокол AH или ESP, которые реализуют нужную защиту и передачу данных.

Нижнй уровень архитектуры основан на домене интерпретации DOI. Протоколы AH и ESP основаны на модульной структуре, разрешая выбор пользователю относительно используемых алгоритмов шифрования и аутентификации. Именно DOI согласует все моменты, и адаптирует IPSec под выбор пользователя.

Формат заголовка пакета AH и ESP показаны на рис.8. Протокол АН защищает весь IP-пакет, кроме полей в Ip-заголовке и поля TTL и типа службы, которые могут модифицироваться при передаче в сети.

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

Протоколы защиты на сеансовом уровне

Протоколы SSL и TLS

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

аутентификация сторон
согласование криптоалгоритмов для реализации
создание общего секретного мастер-ключа
генерация сеансовых ключей на основе мастер-ключа

Процесс аутентификации клиента сервером с помощью протокола SSL виден на рис.11.

Протокол SOCKS

Протокол SOCKS реализует алгоритмы работы клиент/серверных связей на сеансовом уровне через сервер-посредник или прокси-сервер. Изначально этот протокол создавался для перенаправления запросов к серверам от клиентских приложений, и возврата ответа. Такой алгоритм уже разрешает создавать функцию трансляции сетевых IP-адресов NAT. Замена у исходящих пакетов внутренних IP-адресов отправителей разрешает скрыть топологию сети от 3 лиц, тем самым услажняя задачу несанкционированного доступа.

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

Схема создания соединения по протоколу SOCKS v5 описана следующими шагами:

Запрос клиента перехватывает SOCKS-клиент на компьютере
После соединения с SOCKS-сервером, SOCKS-клиент отправляет все идентификаторы всех методов аутентификации, которые он может поддержать
SOCKS-сервер выбирает один метод. Если сервер не поддерживает ни один метод, соединение разрывается
Происходит процесс аутентификации
После успешной аутентификации SOCKS-клиент отправляет SOCKS-серверу IP или ВТЫ нужного узла в сети.
Далее сервер выступает в роли ретранслятора между узлом сети и клиентом

Схема работы по протоколу SOCKS показана на рис.12. Также SOCKS-серверу можно прописывать правила на контроль доступа к внешней сети шлюза. Подходят все правила, которые работают на обычном межсетевом экране.

Протоколы защиты прикладного уровня

Протокол SSH

реализация socks-прокси для приложений, которые не умеют работать с ssh-туннелями
VPN-туннели также могут использовать протокол ssh

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

Советы по безопасности реализации SSH:

запрещение подключение с пустым паролем
выбор нестандартного порта для ssh-сервера
использовать длинные ключи более 1024 бит
настроить файервол
установка IDS

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

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

Сервисы VPN сегодня все чаще встречаются в прошивках беспроводных роутеров и, пожалуй, наибольшее их число представлено в решениях Keenetic, так что именно они и будут использованы в статье. Заметим, что если говорить именно о скорости, очень многое в данном случае зависит и от аппаратной платформы роутера и от программной реализации. Причем второй аспект может быть даже важнее. Кроме того, поскольку прошивки обычно закрытые, то и доступные через Web-интерфейс набор параметров серверов может отличаться. Влияние на производительность, конечно, оказывают и настройки сервисов. В данной статье я обычно использовал заданные производителем значения по умолчанию.

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

Текущая линейка продуктов компании основана на двух моделях процессоров (SoC) производства Mediatek – MT7628 и MT7621. На первом, имеющим одно вычислительное ядро, реализованы модели со 100 Мбит/с портами. Второй, с двумя ядрами, способными исполнять четыре потока, используется в устройствах с гигабитными портами. Более подробную информацию о конфигурациях устройств можно получить, например, в форуме iXBT.

Так что по сути, если взять по одному представителю на каждом чипе, можно охватить всю линейку роутеров компании в описываемой задаче, поскольку Wi-Fi, порты USB и объемы памяти здесь не существенны.

Для теста использовались устройства Keenetic City KN-1510 (младшая из двухдиапазонных) и Keenetic Ultra KN-1810 (старшая модель на данный момент).

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

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

Тестирование проводилось с прошивками версии 3.3.16. Режим подключения к Интернет – IPoE. В тестировании оценивалась скорость доступа внешнего клиента к компьютеру внутри локальной сети за роутером.

PPTP и L2TP

Одни из наиболее известных протоколов для реализации удаленного доступа – PPTP и L2TP. Первый уже считается небезопасным, хотя продолжает использоваться из-за невысокой требовательности к ресурсам. Заметим, что в нем предусмотрен как вариант без шифрования трафика, так и с ним. Одной из особенностей данного решения является использование специального протокола туннелирования, который часто бывает заблокирован домашними провайдерами, что приводит к невозможности использования данного типа подключения. Кроме того, используемые алгоритмы шифрования обычно не «ускоряются» специальными блоками в SoC.

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

Штатные клиенты для этих протоколов существуют во многих операционных системах, включая мобильные, что упрощает настройку подключения. Заметим, однако, что для L2TP обычно используется вариант L2TP/IPSec, в котором кроме привычного имени и пароля пользователя нужно также указать и общий ключ. Он и будет протестирован в этот раз.

Подключить сервисы несложно – после установки соответствующих модулей необходимо в меню «Управление» — «Приложения» включить серверы.

Из настроек предусмотрены разрешение нескольких одновременных входов для одного аккаунта, активация NAT для клиентов (они смогут выходить в Интернет через этот роутер), выбор IP-адресов для выделения клиентам и выбор сегмента сети для доступа.

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

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

При настройке клиентов необходимо указать внешний адрес роутера (IP или имя хоста, что можно реализовать, например, через KeenDNS), аккаунт пользователя, для L2TP/IPSec – дополнительно общий секретный ключ. При работе с PPTP и штатным клиентом Windows необходимо учесть описанные в статье базы знаний особенности.

Для данных протоколов использовались штатные клиенты ОС Windows 10.

Keenetic City в PPTP без шифрования показывает близкие к скорости портов результаты. Хотя, вероятно, мало кого устроит незащищенное от перехвата данных подключение. Использование MPPE в PPTP снижает показатели примерно до 30 Мбит/с, что, в целом, очень неплохо для относительно недорогой модели (напомню, что сходные цифры будут и на самом младшем устройстве текущей линейки). Что касается L2TP/IPSec, то здесь можно рассчитывать не более чем на 10 Мбит/с, поскольку в данном случае применяется шифрование DES, а в Keenetic City оно не поддерживается аппаратно.

Заметно более мощная платформа Keenetic Ultra показывает и более высокие результаты: до 300 Мбит/с в PPTP без шифрования и в среднем около 80 Мбит/с в PPTP с шифрованием и L2TP/IPSec.

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

OpenVPN

Следующий по распространенности в серверах домашних роутеров протокол VPN – OpenVPN. Благодаря реализации с открытым исходным кодом на базе библиотеки OpenSSL, данный протокол очень часто встречается в совершенно разных продуктах, а найти под него клиента не составляет труда для большинства операционных систем.

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

Протокол использует через стандартные соединения TCP или UDP и позволяет выбрать порт. Так что работать с ним можно будет практически в любой ситуации.

В роутерах Keenetic нет отдельного пункта «сервер OpenVPN», данный тип соединений настраивается в разделе «Интернет» — «Другие подключения». Кроме того, потребуется настроить еще несколько опций в других местах (в частности правила для межсетевого экрана), а в некоторых случаях – и в консоли. На сайте поддержки Keenetic этому протоколу посвящено несколько подробных материалов. При определенном опыте, можно реализовать одновременное обслуживание сервером нескольких клиентов. Но это будет явно сложнее, чем простое добавление пользователей в общий список доступа. Для тестов использовался стандартный клиент для Windows с сайта OpenVPN.

По скорости на младшей модели мы получаем до 10 Мбит/с, а на старшей – примерно в два с половиной раза больше. Данный протокол, вероятно из-за своей гибкости, имеет определенные сложности работы через «ускорители», так что скорость работы принесена в жертву универсальности. Впрочем, на других SoC (в частности, топовых Broadcom) его реализация показывает в несколько раз более высокие результаты.

Данный вариант можно рекомендовать сторонникам открытого программного обеспечения и тем, кому требуется максимальная гибкость настройки сервисов. В плюсах также возможность работы по стандартным TCP/UDP соединениям и любым портам.

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

В целом результаты аналогичны предыдущему участнику – до 10 Мбит/с на младшей модели и до 30 Мбит/с на старшей.

IPSec

Эта группа протоколов, пожалуй, наиболее часто упоминается для решения задачи объединения сетей у «больших компаний на серьезном оборудовании». Основной проблемой при работе с IPSec для обычных пользователей является сложность настройки, так что на наш взгляд, его использование с домашним оборудованием является уделом хорошо подготовленных сотрудников ИТ-отделов или энтузиастов. С другой стороны, его реализация в Keenetic присутствует, а на сайте поддержки есть соответствующие статьи базы знаний. Потратив немного больше времени, чем с другими участниками, вполне можно настроить его работу со стандартным клиентом Windows.

Как и для OpenVPN, работа с IPSec осуществляется в разделе «Интернет» — «Другие подключения». Набор параметров явно не для новичка в сетевых технологиях. Нужно выбрать вариант идентификации, опции для двух фаз осуществления соединения, маршруты и так далее. Непросто настроить и соединение со стороны клиента. Можно конечно попробовать действовать «по картинкам», но если что-то пойдет не так, разобраться, не имея определенной базы знаний, будет сложно. Посмотрим, стоила ли игра свеч с точки зрения скорости.

Судя по результатам – вполне. Младшая модель способна обеспечить защищенное соединение со скоростью порядка 50 Мбит/с, а старшая работает в три раза быстрее. Да, конечно это решение не для всех, учитывая сложности настройки. Скорее данный тип соединения будет интересен для сценария объединения сетей, а не подключения удаленных клиентов.

Кстати, в прошивках Keenetic есть и специальный сервер IPSec (Virtual IP), который позволяет легко настроить доступ к роутеру и локальной сети за ним с мобильных устройств на Android и iOS через их штатные клиенты. В нем используется общий ключ и учетная запись пользователя. Остальные параметры установлены автоматичеки по требованиям совместимости с клиентами.

WireGuard

Еще один новый игрок в сегменте VPN-сервисов – протокол WireGuard. Можно сказать, что ему буквально на днях исполнилось два года. Он похож на OpenVPN по своему статусу программного обеспечения с открытым исходным кодом. При этом авторы WireGuard постарались сосредоточиться на использовании современных технологий и протоколов согласования ключей и шифрования и обойти узкие места других реализаций. Это позволило существенно сократить объем кода, оптимизировать скорость и реализовать решение в виде модуля для ядра Linux. В настоящий момент есть клиенты для всех распространенных операционных систем для компьютеров и мобильных устройств.

Сложность настройки в текущей реализации Keenetic можно оценить как среднюю. Сервис заводится в разделе «Интернет» — «Другие подключения» и позволяет также объединять сети, а не только подключать удаленных клиентов. Сначала производится генерация пары ключей (закрытого и публичного) для сервера. На тоже клиенте будет проведена аналогичная операция. В настройках пиров нужно будет указывать публичные ключи второй стороны. Также на стороне роутера присутствует выбор номера порта, подсетей и другие параметры. В случае вопросов, лучше обратиться на сайт поддержки Keenetic, где описаны процедура настройки этого сервиса. Кроме того, потребуется настройка правил межсетевого экрана и маршрутизации. В случае необходимости выхода удаленного клиента в Интернет через роутер нужно будет поработать и в консоли. В фирменном клиенте для Windows конфигурация задается в виде текстового файла. Параметры аналогичны настройкам в роутере. При необходимости на стороне сервера можно запрограммировать несколько пиров, что позволит одному серверу обслуживать одновременно несколько клиентов.

Тестирование показало, что данных протокол выступает по скорости очень хорошо и его результаты сравнимы с традиционным IPSec. Младшая модель способна показать 40-50 Мбит/с, а старшая – 150-220 Мбит/с.

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

Заключение

Все рассмотренные протоколы удаленного доступа имеют свои уникальные особенности и выбор будет зависеть от условий и требований пользователя, включая уровень подготовки и тип операционной системы на клиенте. С точки зрения простоты настройки оптимальным универсальным вариантом можно считать L2TP/IPSec. Однако на младших моделях он все-таки небыстрый, так что и PPTP найдется место. SSTP имеет смысл в случае отсутствия белого адреса на роутере. Если же хочется скорости, то стоит посмотреть в сторону WireGuard, но нужно будет потратить немного больше времени на настройку. OpenVPN и IPSec выберут те, кто уже знаком с этими протоколами и умеет с ними обращаться.

Читайте также: