Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Учебное пособие 800521

.pdf
Скачиваний:
3
Добавлен:
01.05.2022
Размер:
4.21 Mб
Скачать

обмениваются сертификатами и создают защищенное соединение ESP SA (security association). После того как L2TP (поверх IPSec) завершает процесс аутентификации компьютера, выполняется аутентификация на уровне пользователя. Для аутентификации можно задействовать любой протокол, даже PAP, передающий имя пользователя и пароль в открытом виде. Это вполне безопасно, так как L2TP поверх IPSec шифрует всю сессию. Однако проведение аутентификации пользователя при помощи MSCHAP, применяющего различные ключи шифрования для аутентификации компьютера и пользователя, может усилить защиту.

Шифрование

Шифрование с помощью PPTP гарантирует, что никто не сможет получить доступ к данным при пересылке через Internet. В настоящее время поддерживаются два метода шифрования:

-Протокол шифрования MPPE или Microsoft Point-to- Point Encryption совместим только с MSCHAP (версии 1 и 2);

-EAP-TLS и умеет автоматически выбирать длину ключа шифрования при согласовании параметров между клиентом и сервером.

MPPE поддерживает работу с ключами длиной 40, 56 или 128 бит. Старые операционные системы Windows поддерживают шифрование с длиной ключа только 40 бит, поэтому в смешанной среде Windows следует выбирать минимальную длину ключа.

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

111

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

Оба протокола реализованы как в Microsoft Windows, так и вне ее (например, в BSD), на алгоритмы работы VPN могут существенно отличаться. В NT (и производных от нее системах). Основные сведения приведены в таблице. [Приложение 6]

Таким образом, связка «туннелирование + аутентификация + шифрование» позволяет передавать данные между двумя точками через сеть общего пользования, моделируя работу частной (локальной) сети. Иными словами, рассмотренные средства позволяют построить виртуальную частную сеть.

Дополнительным приятным эффектом VPN-соединения является возможность (и даже необходимость) использования системы адресации, принятой в локальной сети.

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

112

шифрования / дешифрования и проверки целостности – аутентификации данных.

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

9.2.SSH

SSH (англ. Secure Shell — «безопасная оболочка») — сетевой протокол прикладного уровня, позволяющий производить удалённое управление операционной системой и туннелирование TCP-соединений (например, для передачи файлов). Схож по функциональности с протоколами Telnet и rlogin, но, в отличие от них, шифрует весь трафик, включая и передаваемые пароли. SSH допускает выбор различных алгоритмов шифрования. SSH-клиенты и SSH-серверы доступны для большинства сетевых операционных систем.

SSH позволяет безопасно передавать в незащищённой среде практически любой другой сетевой протокол. Таким образом, можно не только удалённо работать на компьютере через командную оболочку, но и передавать по шифрованному каналу звуковой поток или видео (например, с веб-камеры). Также SSH может использовать сжатие передаваемых данных для последующего их шифрования, что удобно, например, для удалённого запуска клиентов X Window System.

113

SSH — это протокол прикладного уровня. SSH-сервер обычно прослушивает соединения на TCP-порту 22. Спецификация протокола SSH-2 содержится в RFC 4251. Для аутентификации сервера в SSH используется протокол аутентификации сторон на основе алгоритмов электронноцифровой подписи RSA или DSA, но допускается также аутентификация при помощи пароля (режим обратной совместимости с Telnet) и даже ip-адреса хоста (режим обратной совместимости с rlogin).

-Аутентификация по паролю наиболее распространена. При каждом подключении подобно https вырабатывается общий секретный ключ для шифрования трафика.

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

-Аутентификация по ip-адресу небезопасна, эту возможность чаще всего отключают.

Для создания общего секрета (сеансового ключа) используется алгоритм Диффи — Хеллмана (DH). Для шифрования передаваемых данных используется симметричное шифрование, алгоритмы AES, Blowfish или 3DES. Целостность передачи данных проверяется с помощью

CRC32 в SSH1 или HMAC-SHA1/HMAC-MD5 в SSH2.

Для сжатия шифруемых данных может использоваться алгоритм LempelZiv (LZ77), который обеспечивает такой же уровень сжатия, что и архиватор ZIP. Сжатие SSH включается лишь по запросу клиента, и на практике используется редко.

114

Команда подключения к локальному SSH-серверу из командной строки GNU/Linux или FreeBSD для пользователя pacify (сервер прослушивает нестандартный порт 30000):

$ ssh -p 30000 pacify@127.0.0.1

Генерация пары ключей (в UNIX-подобных ОС) осуществляется командой:

$ ssh-keygen

Генерация пары SSH-2 RSA-ключей длиной 4096 бита программой puttygen под UNIX подобными ОС:

$ puttygen -t rsa -b 4096 -o sample

SSH-туннелирование

SSH-туннель — это туннель, создаваемый посредством SSH-соединения и используемый для шифрования туннелированных данных. Используется для того, чтобы обезопасить передачу данных в Интернете (аналогичное назначение имеет IPsec). При пересылке через SSH-туннель незашифрованный трафик любого протокола шифруется на одном конце SSH-соединения и расшифровывается на другом.

Практическая реализация может выполняться несколькими способами:

-Созданием Socks-прокси для приложений, которые не умеют работать через SSH-туннель, но могут работать через

Socks-прокси

-Использованием приложений, умеющих работать через SSH-туннель.

-Созданием VPN-туннеля, подходит практически для любых приложений.

Если приложение работает с одним определённым сервером, можно настроить SSH-клиент таким образом, чтобы он пропускал через SSH-туннель TCP-соединения, приходящие на определённый TCP-порт машины, на которой запущен SSH-клиент. Например, клиенты Jabber

115

подключаются по умолчанию на порт 443. Тогда, чтобы настроить подключение к серверу Jabber через SSH-туннель, SSH-клиент настраивается на перенаправление подключений с любого порта локальной машины (например, с порта 4430) на удалённый сервер (например, jabber.example.com и порт

443):

$ ssh -L 4430:jabber.example.com:443 somehost

В данном случае Jabber-клиент настраивается на подключение к порту 4430 сервера localhost (если ssh-клиент запущен на той же машине что и Jabber-клиент).

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

Возможно также переадресовывать все соединения на локальный порт через защищенный туннель на удаленную машину. Команда имеет вид:

ssh-L [локальный_адрес:]локальный_порт:удаленный_адрес:удален ный_порт [пользователь@]сервер

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

Отключение доступа пользователю root по SSH. Открыть в текстовом редакторе конфигурационный файл SSH (/etc/ssh/sshd_config):

sudo vim /etc/ssh/sshd_config

116

Найдите в разделе ‘Authentication’ строку с параметром

PermitRootLogin и измените ее вид на:

# Authentication: #LoginGraceTime 2m PermitRootLogin no #StrictModes yes #MaxAuthTries 6

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

Внимание! Перед выполнением вышеуказанного, необходимо создать пользователя, имя которого отлично от ‘root’, и назначить ему права суперпользователя. Это позволит фудаленно выполнять административные задачи.

Предоставление/блокировка доступа для указанных пользователей/групп

По умолчанию авторизоваться может любой пользователь сервера. Лучше ограничить круг пользователей, которым разрешен доступ к ssh. Так же это можно использоваться совместно с NIS или openLDAP (или другие внешние приложения), которым требуется авторизация. Каждый из пользователей вашей компании может иметь учетную запись на серверах NIS, openLDAP и т.п, но на по ssh на некоторые сервера требуется пускать только определенных. Для этого в конфигурационный файл sshd_config следует добавить определенных пользователей, существующих на сервере.

:~$ vi /etc/ssh/sshd_config

AllowUsers ramesh john jason

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

117

:~$ vi /etc/ssh/sshd_config

AllowGroups developers administrators

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

:~$ vi /etc/ssh/sshd_config

DenyUsers cvs apache borya

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

:~$ vi /etc/ssh/sshd_config

DenyGroups marketing staff SSH авторизация по ключу

На локальном компьютере генерируем пару ключей, публичный и приватный командой:

ssh-keygen -t rsa -b 2048 -f ~/.ssh/id_rsa

Задаём пароль для шифрования ключа (!обязательно) -t указывает тип шифрования

-b длину ключа

-f имя и место сохранения (id_rsa по умолчанию!) Копируем публичный ключ (id_rsa.pub) на удалённый

сервер для возможности подключаться: ssh-copy-id -i ~/.ssh/id_rsa.pub user@machine

Файл ключа будет скопирован в конец расположенного на сервере файла

$HOME/.ssh/authorized_keys

Для авторизации только по ключу без возможности входа по паролю на удалённой машине в /etc/ssh/sshd_config делаем:

PasswordAuthentication no

118

Что бы при каждом подключении не вводить пароль ключа:

ssh-add ~/.ssh/id_rsa

9.3.Лабораторная работа № 8

Удаленный доступ в Linux

Цель работы: Ознакомиться на практике со средствами удаленного управления в операционной системе Linux. Приобрести опыт и навыки управления удаленным доступом

Linux.

План проведения занятия

1.Используя теоретические сведения изучить назначение и правила работы с сервисом ssh.

2.Доустановить при необходимости требуемое программное обеспечение (ssh, sshd, putty).

3.Обеспечить доступ по протоколу ssh к своему компьютеру. Предоставить права и пароль для удаленного управления вашим компьютером соседнему - против часовой стрелки - компьютеру.

4.Установить удаленное подключение к удаленному (remote) компьютеру. В качестве Remote выступает соседний по часовой стрелке компьютер. То есть вы должны управлять удаленно правым компьютером, и обеспечить возможность удаленного управления вашим компьютером левому от вас компьютеру.

119

9.4.Контрольные вопросы

1.VPN. Классификация VPN сетей.

2.Методы построения VPN сетей.

3.Туннелирование VPN сетей.

4.Основные VPN протоколы.

5.Методы шифрования.

6.Чем отличаются протоколы L2TP и PPP?

7.Реализация VPN: IPSEC или SSL/TLS?

8.SSH. Основные сведения

120