Защита от хакеров корпоративных сетей

Конфиденциальность: «Куда уходит мой трафик?»

Основополагающими вопросами сохранения тайны коммуникаций, другими словами, их конфиденциальности, являются следующие:

• может ли еще кто-либо контролировать мой трафик внутри туннеля? Ответ на этот вопрос предполагает наличие доступа по чтению к передаваемым по туннелю данным, который может быть получен при предоставлении кому-либо возможности расшифровать передаваемые данные;

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

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

Трассируемость: «Через какую сеть можно передавать данные?»

В основе идеи трассируемости лежат следующие главные вопросы:

• насколько хорошо туннель соответствует ограниченным возможностям маршрутизации пакетов через сеть пользователя? Другими словами, в какой степени характеристики пакетов способствуют их прохождению через сеть пользователя;

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

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

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

Рассмотрим разницу между трафиками, инкапсулированными в протоколы HTTP и HTTPS. По большому счету, протокол HTTPS является протоколом HTTP, заключенным внутри протокола SSL. Другими словами, протокол HTTPS – защищенный вариант протокола HTTP. Передаваемый с помощью протоколов HTTP и HTTPS поток данных пройдет через большинство сетей. Если пользователь пожелает, то туннель протокола HTTP станет для него прозрачным и открытым для исследования. Напротив, для туннеля протокола HTTPS это невозможно. При организации туннеля с помощью протокола HTTPS нет необходимости в фактическом выполнении протокола HTTP, а благодаря использованию SSL туннель получается практически непроницаемым для любознательного администратора. Поэтому по туннелю можно передать все, что угодно. У пользователя нет способа узнать, что именно передается по туннелю, до тех пор, пока у него не появится возможность проверить его состояние.

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

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

Удобство: «Какие усилия могут потребоваться для инсталляции программ и их выполнения?»

Основополагающим для определения возможности инсталляции программ и их выполнения является ответ на следующие два вопроса:

• что нужно установить на стороне клиента, который хотел бы принять участие в передаче данных по туннелю?

• что нужно установить на стороне сервера, который хотел бы принять участие в передаче данных по туннелю?

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

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

Другие системы туннелирования извлекают преимущества из уже размещенных на стороне клиентов программ, обеспечивая для них поддержку сервера. Обычно этот поход позволяет предоставить новые возможности туннелирования гораздо большему числу клиентов, попутно позволяя администратору существенно повысить безопасность всей системы при помощи простых настроек. Например, автоматически перенаправить весь трафик HTTP через шлюз протокола HTTPS или вынудить использующих радиоканал клиентов обращаться к туннелю через протокол PPTP (Point-to-Point Tunneling Protocol – протокол двухточечного туннеля. Новая сетевая технология, которая поддерживает многопротокольные виртуальные частные сети (VPN), позволяя удаленным пользователям безопасно обращаться к корпоративным сетям с помощью коммутируемого соединения, предоставляемого провайдером Интернет или с помощью прямого подключения к Интернету), который является стандартом в операционных системах клиентов.

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

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

Гибкость: «Какие еще существуют варианты использования туннеля?»

Основополагающими вопросами, на которые следует ответить при рассмотрении этого требования, являются следующие:

• что может передаваться по анализируемому туннелю;

• следует ли ожидать неприятностей от чрезмерно большой пропускной способности туннеля?

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

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

При проектировании систем туннелирования может быть использован протокол SSH. Наибольшую производительность систем туннелирования можно достичь при переадресации (forwarding) TCP-сессий. Реализация протокола SSH предусматривает поддержку очень широкого диапазона передаваемых данных, начиная от трафика протокола TCP и заканчивая командами командного процессора для X-приложений, которые могут быть выданы чрезвычайно гибким способом, настраиваемого по мере необходимости. Подобная гибкость делает протокол SSH весьма привлекательным для многих решений туннелирования, хотя и не бесплатно.

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

Несмотря на то что протокол X-Windows на платформе UNIX несколько неуклюж, он является разумной архитектурой графических приложений, используемой для многооконного отображения графики и текста. Одним из его самых больших достоинств является сетевая прозрачность. Окно приложения не обязательно должно быть отображено на компьютере, на котором оно было запущено. Идея заключается в том, что медленные и недорогие аппаратные средства для работы пользователей могут быть развернуты в сети где угодно. Для пользователя это не важно. Но каждое из выполняющихся на них приложений будет «казаться» быстрым, потому что на самом деле приложения выполняются на очень быстром и дорогом сервере, расположенном вдали от любопытных глаз. (Подобные решения годятся для автоматизации задач бизнеса, потому что намного проще получить высокую прибыль на большом сервере, чем на небольших настольных компьютерах. Совсем недавно это своеобразное «вращение карусели» с различным успехом было повторено в Web-сетях, сетевых компьютерах Java и, конечно, в архитектуре. NET.)

Одними из наиболее больших проблем существующих версий X-Windows являются отсутствие в них средств шифрования и, что еще хуже, сложность использования предлагаемых ими средств аутентификации, которые не обеспечивают нужной безопасности (в конце концов, они сводятся к простой проверке способности ответить). Тату Ялонен (Tatu Ylonen) в своем пакете, развивающем возможности прекрасного пакета Secure Shell (SSH), для повышения гибкости безопасной организации сети включил в него очень элегантное решение продвижения данных X-приложений (приложений, работающих по протоколу X-Windows) к месту использования (X-Forwarding). Туннелирование X-трафика по виртуальному отображению туннеля через протокол SSH – сложная и в конечном счете бесполезная процедура управления переменными DISPLAY. Аргументы xhost/xauth были заменены простым вводом ssh user@host и запуском X-приложения при помощи командного процессора. Защита – это прекрасно, но давайте скажем откровенно: «Вопреки ожиданиям только это и сработало!»

Решение было и продолжает оставаться блестящим. Оно расценивается как один из лучших примеров наиболее очевидного, но зачастую невозможного следования закону усовершенствования проекта: «Не сделайте хуже». Даже лучшие решения систем безопасности или туннелирования могут оказаться не вполне удобными для использования. Как минимум, они потребуют дополнительных действий, возможно, немного везения при обработке данных и вызовут легкое замешательство пользователя или снижение производительности сети (в терминах времени ожидания или пропускной способности). Это неизбежное следствие обмена свободы на безопасность, хотя при туннелировании свобода несильно отличается от компьютерной безопасности. Даже простое закрытие двери квартиры на ключ обязывает хозяина квартиры помнить место хранения ключа, замедляя его доступ в собственную квартиру. Если хозяин квартиры забудет ключ от входной двери или место его хранения, то придется столкнуться с дополнительными издержками (как, например, в случае хранения ключа у друга или администратора для восстановления доступа к своей собственности потребуется срочно позвонить ему по телефону). В конце концов, для сдерживания решительно настроенного грабителя недостаточно просто запереть дверь! Таким образом, затруднение в использовании и недостаточная эффективность являются предметом уже состоявшегося разговора.

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

Что произойдет, если сервер был скомпрометирован?

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

Возможное решение состояло в отключении возможности продвижения данных X-приложений по умолчанию. В настоящее время в OpenSSH реализована команда ssh – X user@host, которая делает это при условии реализации точно такой же возможности на сервере. (Нет, это еще не законченное решение. В случае возникновения у клиента необходимости отправки X-трафика скомпрометированный сервер все еще может попытаться эксплуатировать клиента с нарушением установленных режимов работы. Но на некотором этапе проблема превращается в проблему собственно X-трафика, и в большинстве сессий протокол SSH ничего не может с этим поделать. Большинство сессий может быть сделано безопасными простым отключением опции по умолчанию. Гораздо более безопасным решением является пересылка X-трафика при помощи программного обеспечения VNC (Virtual Network Computing – виртуальная сетевая обработка данных), что во многих сравнительно медленных сетевых топологических схемах устанавливается быстрее, проще, а работает гораздо стабильнее. Подробнее об этом можно узнать по адресу www.tightvnc.org.).

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

Качество: «Насколько безболезненно обслуживание системы?»

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

• можно ли реализовать задуманное;

• будет ли устойчив полученный результат;

• будет ли реализация достаточно быстра?

Есть несколько простых вещей, про которые читатель может подумать, что они очевидны. Некоторые базовые концепции выглядят настолько естественными, что никто даже и подумал бы предположить что-либо другое. Можно полагать, что к ним принадлежит идея удобства и простоты использования системы. Если система непригодна, то никому и в голову не придет использовать ее. Читатель может подумать, что словосочетание «непригодно для использования» означает систему, которая охотно поделится конфиденциальной информацией с первым встречным, но на самом деле это не так. В последнее время появилось слишком много систем, которые таковыми в буквальном смысле не являются, но из-за их чрезмерной сложности их нельзя модернизировать, подделать, использовать в своих целях, адаптировать к нуждам конкретного сайта или сделать с ними еще что-нибудь, поэтому все силы уходят на то, чтобы они вообще заработали. Такие системы не приветствуются даже в области обеспечения безопасности. Те, кто боится сломать их, избегают вносить в них исправления. (На многие, очень многие сервера не устанавливаются патчи, латающие дыры в системе безопасности сервера, только потому, что получила распространение очень простая логика, согласно которой исправленный сервер злоумышленник может и не атаковать, а обновляющий сервер патч наверняка содержит ошибки.) Поэтому на самом деле основные вопросы к любой системе туннелирования состоят в следующем: «Можно ли, приложив разумные усилия, сначала установить систему, а затем поддерживать ее силами обслуживающего персонала? Насколько надежна настройка системы? Каков риск простоя системы во время ее использования после проведенной модернизации?»

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