Диагностиика локальной сети

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

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

Таким образом, проблема диагностики компьютерных сетей является актуальной и в  конечном счете, диагностирование неисправностей является задачей управления. Для  большинства критически важных корпоративных  систем, проведение продолжительных восстановительных работ не допустимо, поэтому единственным решением будет использование резервных устройств и процессов, способных взять на себя необходимые функции немедленно после возникновения сбоев. На некоторых предприятиях сети всегда имеют дополнительный резервный компонент на случай сбоя основного, т. е. n х 2 компонентов, где n — количество основных компонентов, необходимое для обеспечения приемлемой производительности. Если среднее время восстановления (Mean Time To Repair, MTTR) достаточно велико, то может понадобиться еще большая избыточность. Дело в том, что время устранения неисправности предсказать нелегко, а значительные затраты в течение непредсказуемого периода восстановления являются признаком плохого управления.

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

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

 

2.Протокол SSL

SSL (англ. Secure Sockets Layer — уровень защищённых сокетов)  — криптографический протокол, который  обеспечивает установление безопасного  соединения между клиентом и  сервером. SSL изначально разработан  компанией Netscape Communications. Впоследствии на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS.

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

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

SSL предоставляет  канал, имеющий 3 основных свойства:

Аутентификация. Сервер всегда аутентифицируется, в  то время как клиент аутентифицируется  в зависимости от алгоритма.

Целостность. Обмен сообщениями включает в себя проверку целостности.

Конфиденциальность  канала. Шифрование используется после  установления соединения и используется для всех последующих сообщений.

В протоколе SSL все данные передаются в виде записей-объектов, состоящих из заголовка и передаваемых данных. Передача начинается с заголовка. Заголовок содержит либо два, либо три байта кода длины. Причём, если старший бит в первом байте кода равен единице, то запись не имеет заполнителя и полная длина заголовка равна двум байтам, иначе запись содержит заполнитель и полная длина заголовка равна трём байтам. Код длины записи не включает в себя число байт заголовка. Длина записи 2-байтового заголовка:

RecLength = ((byte[ 0 ] & 0x7F) << 8) | byte[ 1 ];

Здесь byte[0] и byte[1] — первый и второй полученные байты. Длина записи 3-байтового заголовка:

RecLength = ((byte[ 0 ] & 0x3F) << 8) | byte[ 1 ];

Escape = (byte[ 0 ] & 0x40) != 0;

Padding = byte[ 2 ];

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

 Теперь отправитель  «заполненной» записи добавляет  заполнитель после имеющихся  данных и шифрует всё это.  Причем, содержимое заполнителя  никакой роли не играет. Из-за того, что известен объём передаваемых данных, заголовок может быть сформирован с учетом Padding.

 В свою  очередь получатель записи дешифрует  все поля данных и получает  полную исходную информацию. Затем  производится вычисление значения RecLength по известному Padding, и заполнитель из поля данных удаляется. Данные записи SSL состоят из 3 компонент:

MAC_Data[Mac_Size] —  (Message Authentication Code) — код аутентификации  сообщения

Padding_Data[Padding] —  данные заполнителя

Actual_Data[N] — реальные данные

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

MacData = Hash(Secret, Actual_Data, Padding_Data, Sequence_Number);

Значение Secret зависит  от того, кто (клиент или сервер) посылает сообщение. Sequence_Number — счётчик, который  инкрементируется как сервером, так  и клиентом. Здесь Sequence_Number представляет собой 32-битовый код, передаваемый хэш-функции в виде 4 байт, причём, первым передаётся старший байт. Для MD2, MD5 MAC_Size равен 16 байтам (128 битам). Для 2-байтового заголовка максимальная длина записи равна 32767 байтов, а для 3-байтного заголовка — 16383 байтов.

Основные цели протокола в порядке приоритетности

Криптографическая безопасность: SSL устанавливает безопасное соединение между двумя сторонами.

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

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

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

Атаки.

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

Взлом SSL-соединений агентами ФБР с помощью систем Carnivore и NarusInsight

Наиболее известный  инцидент по массовому взлому информации, защищенной протоколами SSL, был произведен агентами ФБР с помощью систем Carnivore и NarusInsight, что привело к судебному процессу от лица правозащитной организации Electronic Frontier Foundation против AT&T, который установил данные комплексы для взлома криптографически защищенной информации.

Несмотря на высокий общественный резонанс в  США данного дела и расследование  на уровне конституционного комитета Палаты представителей, технологически взлом протокола SSL агентами ФБР не производился. Carnivore и NarusInsight были установлены в самом ЦОД, где находились сервера, ведущие SSL-соединенения с удаленными клиентами. NarusInsight полностью восстановил зашифрованную информацию путем прослушивания не SSL-соединения, а внутреннего траффика между серверами приложений внутри самого ЦОД, уже после того как данные, поступившие по SSL, были расшифрованы самим сервером, их принявшим от внешних пользователей.

Тем не менее, указанный  инцидент показал, что SSL не может являться надежным средством криптозащиты данных серверов в Интернете, так как спецслужбы могут установить системы прослушивания, такие как NarusInsight или СОРМ-2, в ЦОД. Любой вид криптографии, подразумевающий, что ключи от шифров находятся у сервера-получателя в ЦОД, взламываются снифферами спецслужб в автоматическом режиме за счет внедрения их в самого получателя. Далее данные полностью реконструируются по процедурам, которые на данный момент регулируются и законодательными актами, такими как «Патриотический акт». Причем указанные законодательные акты запрещают вплоть до судебного преследования владельцев ЦОД удаление снифферов спецслужб из внутренней части серверов-получателей. С учетом наличия данных систем, протокол SSL может защищать только соединение двух пользователей в Интернете, но не SSL-соединение с внешним Web-сайтом.

Раскрытие шифров.

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

Злоумышленник посередине.

Также известна как MitM (Man-in-the-Middle) атака. Предполагает участие трех сторон: сервера, клиента и злоумышленника, находящегося между ними. В данной ситуации злоумышленник может перехватывать все сообщения, которые следуют в обоих направлениях, и подменять их. Злоумышленник представляется сервером для клиента и клиентом для сервера. В случае обмена ключами по алгоритму Диффи-Хелмана данная атака является эффективной, так как целостность принимаемой информации и ее источник проверить невозможно. Однако такая атака невозможна при использовании протокола SSL, так как для проверки подлинности источника (обычно сервера) используются сертификаты, заверенные центром сертификации.

Атака будет  успешной, если:

Сервер не имеет  подписанного сертификата.

Клиент не проверяет  сертификат сервера.

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

Данный вид атаки можно встретить в крупных организациях, использующих межсетевой экран Forefront TMG компании Microsoft. В данном случае "злоумышленник" находится на границе сети организации и производит подмену оригинального сертификата своим. Данная атака становится возможной благодаря возможности указать в качестве доверенного корневого центра сертификации сам Forefront TMG. Обычно подобная процедура внедрения проходит прозрачно для пользователя за счет работы корпоративных пользователей в среде Active Directory. Данное средство может использоваться как для контроля за передаваемой информацией, так и в целях похищения личных данных, передаваемых с помощью защищенного соединения HTTPS.