Защита информации в Интернет

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

Основной проблемой Интернета как канала передачи информации является возможность атаки “man in the middle”. Злоумышленник подключается к линии между клиентом и сервером и подменяет передающуюся информацию. Возможны совершенно разные варианты этой атаки. Например, злоумышленник может "прикидываться" сервером и вводить клиента в заблуждение с целью извлечь выгоду из обмана. Следует отметить, что наиболее легко эту атаку может реализовать Интернет-провайдер. С целью обеспечения безопасного обмена разработаны различные протоколы защиты и созданы программные продукты, реализующие данные протоколы.

1. Протоколы формирования защищенных каналов на канальном уровне

защита информация протокол канал

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

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

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

Для защиты информационного обмена на сеансовом уровне широкое распространение получил протокол SSL (Secure Sockets Layer). Для выполнения на сеансовом уровне функций посредничества между взаимодействующими сторонами организацией IETF (Internet Engineering Task Force) в качестве стандарта принят протокол SOCKS.

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

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

Взаимная аутентификация обеих сторон в SSL выполняется путем обмена цифровыми сертификатами открытых ключей пользователей (клиента и сервера), заверенными цифровой подписью специальных сертификационных центров. Протокол SSL поддерживает сертификаты, соответствующие общепринятому стандарту Х.509, а также стандарты инфраструктуры открытых ключей PKI (Public Key Infrastructure), с помощью которой организуется выдача и проверка подлинности сертификатов.

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

В качестве алгоритмов асимметричного шифрования используются алгоритм RSA, а также алгоритм Диффи -- Хеллмана. Допустимыми алгоритмами симметричного шифрования являются RC2, RC4, DES, 3DES и AES. Для вычисления хэш-функций могут применяться стандарты MD5 и SHA-1.

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

Рис. 5. Криптозащищенные туннели, сформированные на основе протокола SSL

Протокол SSL предусматривает следующие этапы взаимодействия клиента и сервера при формировании и поддержке защищаемого соединения:

* установление SSL-сессии;

* защищенное взаимодействие.

В процессе установления SSL-сессии решаются следующие задачи:

* аутентификация сторон;

* согласование криптографических алгоритмов и алгоритмов сжатия, которые будут использоваться при защищенном информационном обмене;

* формирование общего секретного мастер-ключа;

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

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

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

Протокол SSL поддерживает три режима аутентификации:

* взаимную аутентификацию сторон;

* одностороннюю аутентификацию сервера без аутентификации клиента;

* полную анонимность.

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

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

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

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

Протокол SOCKS

Протокол SOCKS организует процедуру взаимодействия клиент-серверных приложений на сеансовом уровне модели OSI через сервер-посредник, или proxy-сервер.

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

* идентификацию и аутентификацию пользователей;

* криптозащиту передаваемых данных;

* разграничение доступа к ресурсам внутренней сети;

* разграничение доступа к ресурсам внешней сети;

* фильтрацию и преобразование потока сообщений, например поиск вирусов и прозрачное шифрование информации;

* трансляцию внутренних сетевых адресов для исходящих потоков сообщений.

Первоначально протокол SOCKS разрабатывался только для перенаправления запросов к серверам со стороны клиентских приложений, а также возврата этим приложениям полученных ответов. Перенаправление запросов и ответов между клиент-серверными приложениями уже позволяет реализовать функцию трансляции сетевых IP-адресов NAT (Network Address Translation). Замена у исходящих пакетов внутренних IP-адресов отправителей одним IP-адресом шлюза позволяет скрыть топологию внутренней сети от внешних пользователей и тем самым усложнить задачу НСД.

На основе протокола SOCKS могут быть реализованы и другие функции посредничества по защите сетевого взаимодействия. Например, протокол SOCKS может применяться для контроля над направлениями информационных потоков и разграничения доступа в зависимости от атрибутов пользователей и информации. Эффективность использования протокола SOCKS для выполнения функций посредничества обеспечивается его ориентацией на сеансовый уровень модели OSI. По сравнению с посредниками прикладного уровня на сеансовом уровне достигается более высокое быстродействие и независимость от высокоуровневых протоколов (HTTP, FTP, РОРЗ, SMTP и др.). Кроме того, протокол SOCKS не привязан к протоколу IP и не зависит от ОС. Например, для обмена информацией между клиентскими приложениями и посредником может использоваться протокол IPX.

Благодаря протоколу SOCKS МЭ и виртуальные частные сети могут организовать безопасное взаимодействие и обмен информацией между разными сетями. Протокол SOCKS позволяет реализовать безопасное управление этими системами на основе унифицированной стратегии. Следует отметить, что на основе протокола SOCKS могут создаваться защищенные туннели для каждого приложения и сеанса в отдельности.

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

Общая схема установления соединения по протоколу SOCKS v5 может быть описана следующим образом:

* запрос прикладного клиента, желающего установить соединение с каким-либо прикладным сервером в сети, перехватывает установленный на этом же компьютере SOCKS-клиент;

* соединившись с SOCKS-сервером, SOCKS-клиент сообщает ему идентификаторы всех методов аутентификации, которые он поддерживает;

* SOCKS-сервер решает, каким методом аутентификации воспользоваться (если SOCKS-сервер не поддерживает ни один из методов аутентификации, предложенных SOCKS-клиентом, соединение разрывается);

* при поддержке каких-либо предложенных методов аутентификации SOCKS-сервер в соответствии с выбранным методом аутентифицирует пользователя, от имени которого выступает SOCKS-клиент; в случае безуспешной аутентификации SOCKS-сервер разрывает соединение;

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

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

Аутентификация пользователя, выполняемая SOCKS-сервером, может основываться на цифровых сертификатах в формате Х.509 или паролях. Для шифрования трафика между SOCKS-клиентом и SOCKS-сервером могут быть использованы протоколы, ориентированные на сеансовый или более низкие уровни модели OSI. Кроме аутентификации пользователей, трансляции IP-адресов и криптозащиты трафика, SOCKS-сервер может выполнять также такие функции, как:

* разграничение доступа к ресурсам внутренней сети;

* разграничение доступа к ресурсам внешней сети;

* фильтрация потока сообщений, например, динамический поиск вирусов;

* регистрация событий и реагирование на задаваемые события;

* кэширование данных, запрашиваемых из внешней сети.

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

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

Рис. 6. Схема взаимодействия по протоколу SOCKS

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

Помимо защиты локальной сети от НСД, на SOCKS-сервер может возлагаться контроль доступа пользователей этой локальной сети к открытым ресурсам Интернета (Telnet, WWW, SMTP, POP и др.). Доступ является полностью авторизованным, так как идентифицируются и аутентифицируются конкретные пользователи, а не компьютеры, с которых они входят в сеть. Правила доступа могут запрещать или разрешать соединения с конкретными ресурсами Интернета в зависимости от полномочий конкретного сотрудника. Действие правил доступа может зависеть и от других параметров, например от метода аутентификации или времени суток.

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

3. Построение виртуальной частной сети (VPN)

VPN (англ. Virtual Private Network -- виртуальная частная сеть) -- обобщённое название технологий, позволяющих обеспечить одно или несколько сетевых соединений (логическую сеть) поверх другой сети (например, Интернет). Несмотря на то, что коммуникации осуществляются по сетям с меньшим неизвестным уровнем доверия (например, по публичным сетям), уровень доверия к построенной логической сети не зависит от уровня доверия к базовым сетям благодаря использованию средств криптографии (шифрования, аутентификации, инфраструктуры открытых ключей, средств для защиты от повторов и изменений, передаваемых по логической сети сообщений). В зависимости от применяемых протоколов и назначений, VPN может обеспечивать соединения трёх видов: узел-узел, узел-сеть и сеть-сеть. На рисунке 7 показан пример Виртуальной частной сети в интернете.

Рис.7 VPN в интернете

Организовывая безопасные каналы передачи информации в учреждениях несправедливо не рассмотреть вариант организации полноценной частной сети. На рисунке 8 ниже изображен вариант организации частной сети небольшой компанией с 2 филиалами.

Рис 8 Организация частной сети

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

высокая скорость передачи информации, фактически скорость при таком соединении будет равна скорости локальной сети предприятия;

безопасность, передаваемые данные не попадают в сеть общего пользования;

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

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

Рис. 9 Частная виртуальная сеть

В данном случае преимущества , приведенные для частных сетей, оборачиваются недостатками для виртуальных частных сетей, но так ли значительны эти недостатки? Давайте разберемся:

скорость передачи данных. Провайдеры могут обеспечить достаточно высокоскоростной доступ в Интернет, однако с локальной, проверенной временем 100 Мбит сетью он все равно не сравнится. Но так ли важно каждый день перекачивать сотни мегабайт информации через организованную сеть? Для доступа к локальному сайту предприятия, пересылки электронного письма с документом вполне достаточно скорости, которой могут обеспечить Интернет-провайдеры;

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

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

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

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

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

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

Способы организации

В VPN наиболее целесообразно выделить следующие три основных способа:

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

Рис. 10 Организация VPN поверх Internet

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

Данный способ организации виртуальной частной сети целесообразно применять в случаях:

географически не привязанного доступа сотрудников к корпоративной сети организации;

доступа к Интернету. Часто провайдеры создают для своих клиентов VPN подключения для организации доступа к ресурсам Интернет.

Связь в одну общую сеть территориально распределенных филиалов фирмы. Этот способ называется Intranet VPN рис. 11.

Рис.11 Intranet VPN

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

Данный способ целесообразно использовать как для обыкновенных филиалов, так и для мобильных офисов, которые будут иметь доступ к ресурсам «материнской» компании, а также без проблем обмениваться данными между собой.

Так называемый Extranet VPN, когда через безопасные каналы доступа предоставляется доступ для клиентов организации. Набирает широкое распространение в связи с популярностью электронной коммерции.

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

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

протоколы, инкапсулирующие данные и формирующие VPN соединение;

протоколы, шифрующие данные внутри созданного туннеля.

Первый тип протоколов устанавливает туннелированное соединение, а второй тип отвечает непосредственно за шифрование данных. Рассмотрим некоторые стандартные, предлагаемые всемирно признанным мировым лидером в области разработки операционных систем, решения.

В качестве стандартного набора предлагается сделать выбор из двух протоколов, точнее будет сказать наборов:

PPTP (Point-to-Point Tunneling Protocol) - туннельный протокол «точка-точка», детище Microsoft и является расширением PPP (Point-to-Point Protocol), следовательно, использует его механизмы подлинности, сжатия и шифрования.

L2TP (Layer Two Tunneling Protocol) - более совершенный протокол, родившийся в результате объединения протоколов PPTP (от Microsoft) и L2F (от Cisco), вобравший в себя все лучшее из этих двух протоколов.

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

Если смотреть RFC2661, то можно видеть, что L2TP использует всего 1 порт для работы 1701 (TCP/UDP), а PPTP (RFC 2637) использует туннелирование GRE(IP протокол номер 47) да еще и порт TCP 1723. PPTP сложно перенаправлять за сетевой экран, так как он требует одновременного установления двух сетевых сессий.

Механизм защиты IPSec L2TP гораздо лучше, чем CHAP (нешифрованный пароль) или MS-CHAP. Узнав пароль, все эти защиты бесполезны. Конечно, можно использовать что-то типа EAP-TLS, но сертификаты не переносимы! И если пользователю понадобится позаимствовать чужой ноутбук или потребуется заменить вышедший из строя компьютер, осложнений не избежать, ведь для того, чтобы пользователь мог подключиться к VPN и войти в сеть, придется предварительно установить на его машине сертификат, созданный именно для этого пользователя.

L2TP - усиленная двухфакторная аутентификация, и шифрование, и целостность данных. Когда с помощью протокола L2TP выполняется подключение к серверу VPN, для аутентификации систем этот протокол использует сертификаты клиентских и серверных машин. После успешного завершения процедуры аутентификации L2TP устанавливает соединение по протоколу IP Security (IPSec) в режиме Encapsulating Security Payload (ESP). До этого момента L2TP зашифровывал все данные, проходящие через VPN в Internet, защитил соединение от «атак через посредника» и завершил первый уровень аутентификации.

Практическая реализация

Теперь перейдем от теории к практике, ведь, как известно: «практика - критерий истины». Попробуем организовать простой вариант виртуальной частной сети, изображенный на рис.12 ниже.

Рис. 12 Вариант частной сети

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

Адрес сети, к которой необходимо получить доступ 11.7.0.0 маска подсети соответственно 255.255.0.0. Данная корпоративная сеть - это доменная сеть, под управлением Windows 2003 Server Corporate Edition. На сервере имеется два сетевых интерфейса с IP адресами, внутренним для корпоративной сети 11.7.3.1 и внешним 191.168.0.2. Следует отметить, что при проектировании сети VPN сервер ставится в самую последнюю очередь, поэтому Вы сможете без особых проблем организовать VPN доступ к уже отлаженной и сформированной сети организации, но, в тоже время, если в управляемой сети произошли существенные изменения, то, возможно, Нам потребуется перенастроить VPN сервер.

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

В Windows 2003 Server установка роли VPN сервера осуществляется достаточно просто рис.13.

Рис. 13 Настройка VPN

Следуя подсказкам мастера, устанавливаем необходимые параметры: на втором шаге выбираем удаленный доступ (VPN или модем); потом удаленный доступ через Интернет; на 4-м шаге указываем интерфейс сервера, подключенный к Интернету, в нашем случае 191.168.0.2; далее определяем способ назначения адресов удаленным клиентам, в нашем случае это будут автоматически назначенные адреса; если у Вашей сети имеется RADIUS сервер, для централизованной проверки подлинности подключений, выберете его, если нет, тогда оставьте эту задачу VPN серверу.

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

Рис. 14 Изменение параметров

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

С серверной частью закончили, переходим к созданию клиента виртуальной частной сети на удаленном компьютере. Для этого необходимо запустить мастер сетевых подключений. На втором шаге, следуя подсказкам, выбрать пункт «Подключить к сети на рабочем месте». На третьем шаге «Подключение к виртуальной частной сети». Следующий шаг - вводим название подключения. Пятый шаг - выбираем, следует ли предварительно подключаться к Интернету (если Вы подключаетесь с места с постоянным доступом, выберете «нет», если же используете, например, мобильный телефон в качестве модема, тогда следует выбрать предварительный набор номера для подключения к Интернету). На предпоследнем шаге вводим IP-адрес сервера, к которому осуществляется доступ Рис. 15.

Рис. 15 Ввод адреса назначения

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

Рис.16 Изменения типа VPN

Проверка

Конфигурирование удаленного доступа завершено, пришло время проверить его работоспособность. Начнем традиционно, со всеми любимой команды «ping», просто попробуем «пропинговать» какую-нибудь рабочую станцию из нашей корпоративной сети Рис. 17.

Рис. 17 Проверка работоспособности

Заключение

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

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

Размещено на Allbest.ru