Заключительные замечания

Рассмотренные выше примеры относятся к реально существующим изученным авторами системам. Читатели могут встретиться с системами, требующими реализации в сценарии некоторых других особенностей. Разработка сценария для конкретной ситуации — это путь проб и ошибок. Для написания сценариев можно использовать и другие языки, однако этот метод был выбран для простоты. Напомним еще раз, что для реализации этого подхода сначала необходимо открыть файл журнала, поскольку после успешного написания сценария и его многочасовой работы будет очень обидно обнаружить полное отсутствие результатов.
Читателей может заинтересовать вопрос: а как обстоят дела с соединениями ISDN (Integrated Services Digital Network)? Они по-прежнему используются во многих компаниях. Эти соединения в свое время предназначались для ускорения процесса соединения с корпоративной сетью. На сегодняшний день более быстрые каналы Internet во многом вытеснили соединения ISDN, однако последние все еще используются. Поэтому наряду с выявлением аналоговых линий обычных телефонных соединений имеет смысл проводить сканирование в поисках ISDN-модемов (или, как их часто называют, терминальных адаптеров (terminal adapters)). Авторы не имеют возможности привести полное описание процесса сканирования, направленного на выявление ISDN-соединений, в настоящем издании. Возможно, это будет сделано в следующем издании книги.
Теперь самое время перейти к рассмотрению способов защиты перечисленных выше слабых мест.

Защита удаленных соединений

Не мудрствуя лукаво, приведем список вопросов, которые необходимо решить в процессе планирования защиты удаленных соединений своей организации. Этот список упорядочен по сложности реализации мероприятий (от простого к сложному). Поэтому в первую очередь будут устранены проблемы, относящиеся к домену ЛДП. Внимательному читателю этот список наверняка напомнит перечень мероприятий в рамках политики защиты удаленных соединений.
1. Выполните инвентаризацию всех существующих линий удаленных соединений. На первый взгляд, это непростая задача. Однако перечитайте еще раз эту главу и обратите внимание на многократное повторение терминов "автопрозвон" или "сканирование телефонных номеров". Выявите все возможности неавторизованных удаленных соединений и избавьтесь от них всеми доступными средствами.
2. Внесите всю информацию об удаленных соединениях в единый банк данных, вынесите его за пределы внутренней сети как банк ненадежных соединений (т.е. в демилитаризованную зону), а затем, применив методы выявления вторжений и технологию брандмауэров, ограничьте доступ к доверенным подсетям.
3. Постарайтесь усложнить поиск аналоговых линий. Не назначайте их в одном диапазоне с телефонными номерами корпорации и не передавайте телефонные номера компании для регистрации в базе данных InterNIC. Защитите паролем информацию о телефонных номерах на АТС.
4. Удостоверьтесь, что телекоммуникационное оборудование защищено физически: во многих компаниях такое оборудование содержится в общедоступных местах в незакрывающихся боксах.
5. Регулярно проверяйте журналы регистрации программного обеспечения удаленных соединений. Особое внимание уделите информации о неудачных попытках установки соединений, активности в ночное время и необычным ситуациям. Используйте CalledD для записи номеров всех входящих соединений.
6. Важно и просто! Для линий, применяемых в коммерческих целях, отключите вывод любых идентификационных данных и замените их на наиболее нейтральное приглашение. Рассмотрите возможность отправки предупреждающих сообщений о недопустимости несанкционированного использования.
7. Предусмотрите для удаленного доступа двойную аутентификацию. Двойная аутентификация (two-factor authentication) предполагает ввод пользователем для получения доступа к системе двух типов данных: то, что он имеет, и то, что он знает. Примером являются одноразовые карточки паролей SecurlD компании Security Dynamics Technologies, Inc. Понятно, что зачастую такой подход финансово невыгоден. Однако это наилучший способ предотвращения большинства описанных выше проблем. В заключительном разделе главы приводится перечень компаний, выпускающих подобные продукты. В случае отказа от их услуг необходимо придерживаться жесткой политики назначения сложных паролей.
8. Требуйте аутентификации по обратной связи. Аутентификация по обратному звонку (dial-back) подразумевает такую конфигурацию удаленной системы, при которой сразу же после установки соединения с любым из клиентов это соединение разрывается и возобновляется снова по инициативе самой удаленной системы по заранее известным координатам инициатора соединения. С целью обеспечения более высокой степени безопасности при установке обратного соединения желательно использовать отдельный модемный пул, для которого запрещены входящие соединения (средствами модемов или самих телефонных линий). Следует иметь в виду, что такое решение, видимо, неприемлемо для многих современных компаний с большим количеством мобильных пользователей.
9. Удостоверьтесь, что доска объявлений компании не содержит секретных данных и не обеспечивает возможности удаленного изменения параметров учетной записи. Все описанные выше меры безопасности окажутся тщетными, если в отделе технической поддержки компании появится один новый энергичный человек с недобрыми намерениями.
10. Сосредоточьте решение задач обеспечения удаленных соединений (начиная от факсов и заканчивая голосовой почтой) в руках одного отдела своей организации, уполномоченного решать задачи безопасности.
11. Установите корпоративную политику для сотрудников центрального подразделения таким образом, чтобы полностью исключить обычные телефонные соединения. С этой целью установите внутренние мини-АТС, исключающие прямые входящие телефонные звонки и обеспечивающие лишь передачу исходящих факсов, доступ к электронной доске объявлений и т.п. Проведите тщательный маркетинг соответствующих систем и удостоверьтесь, что выбранная вами внутренняя мини-АТС удовлетворяет всем необходимым требованиям безопасности. В противном случае перейдите к п.1 и укажите поставщикам на бреши в защите, выявленные по методологии сканирования телефонных номеров.
12. Вернитесь к п.1. Изящно сформулированные политики — это хорошо, однако единственный способ обеспечить следование этим политикам состоит в регулярном сканировании телефонных линий на предмет поиска новых брешей в защите. Авторы советуют проводить эту операцию не реже двух раз в год для компаний с 10000 телефонных линий, а желательно даже чаще. Итак, защита удаленных соединений включает 12 пунктов. Конечно же, некоторые из них достаточно сложно воплотить в жизнь, однако стоит приложить для этого максимум усилий. Многолетний опыт авторов по обеспечению безопасности больших корпораций свидетельствует о том, что большинство компаний хорошо защищено брандмауэрами, однако практически все имеют бреши в защите обычных телефонных линий, позволяющие добраться к самому сердцу информационной инфраструктуры. Не лишним будет повторить, что война с модемами — возможно, самый важный шаг к улучшению безопасности сети организации.

Хакинг удаленных внутренних телефонных сетей РВХ

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

Доступ к телефонной сети от компании Octel

В телефонных сетях РВХ от компании Octel пароль администратора обязательно является числом. Иногда это играет очень важную роль. По умолчанию почтовый ящик системного администратора во многих системах компании Octel — 9999.

XX-Feb-XX 05:03:56 *91ХХХ5551234 С: CONNECT 9600/ARQ/V32/LAPM
Welcome to the Octel voice/data network.
All network data and programs are the confidential and/or
proprietary property
of Octel Communications Corporation and/or others.
Unauthorized use, copying, downloading, forwarding or
reproduction in any form by any person of any network
data or program is prohibited.
Copyright (C) 1994-1998 Octel Communications Corporation.
All Rights Reserved.
Please Enter System Manager Password:
Здесь необходимо ввести число
Enter the password of either
System Manager mailbox, then press
"Return."

Система РВХ от компании Williams

Как правило, работа в системе РВХ компании Williams происходит так, как показано ниже. При регистрации в сети зачастую требуется ввести номер пользователя. Обычно это пользователь первого уровня, номер которого — четырехзначное число. Очевидно, что подобрать нужное четырехзначное число не составляет труда.

XX-Feb-XX 04:03:56 *91ХХХ5551234 С:
CONNECT 9600/ARQ/V32/LAPM
OVL111 IDLE 0
>
OVL111 IDLE 0
>
OVL111 IDLE 0
>
OVL111 IDLE 0

Система Meridian

На первый взгляд, система Meridian напоминает операционную систему UNIX. Однако воздержитесь от ее покупки! При вводе идентификатора пользователя maint с таким же паролем обеспечивается доступ к управляющей консоли. Тот же результат достигается при вводе идентификатора пользователя mluser с одноименным паролем Это две различные оболочки в стиле UNIX, предназначенные для ограничения взаимодействия с системой РВХ. Однако эти ограничения очень легко обойти.

XX-Feb-XX 02:04:56 *91ХХХ5551234
С: CONNECT 9600/ARQ/V32/LAPK
login:
login:
login:
login:

Система ROLM PhoneMail

Приведенное ниже поведение свойственно устаревшей системе ROLM PhoneMail. При входе в нее иногда даже отображаются соответствующие идентификационные маркеры.

XX-Feb-XX 02:04:56 *91ХХХ5551234 С: CONNECT 9600/ARQ/V32/LAPM
РМ Login>
Illegal Input.

LOGIN: sysadrain PASSWORD: sysadmin
LOGIN: tech PASSWORD: tech
LOGIN: poll PASSWORD: tech

Система ATT Definity 75

Система ATT Definity 75 — одна из старейших систем РВХ, и ее приглашение выглядит как стандартное приглашение UNIX. Иногда при этом выводятся даже соответствующие идентификационные маркеры.

ATT UNIX S75
Login:
Password:

Login: enquiry Password: enquirypw
Login: init Password: initpw
Login: browse Password: looker
Login: maint Password: rwmaint
Login: locate Password: locatepw
Login: rcust Password: rcustpw
Login: tech Password: field
Login: cust Password: custpw
Login: inads Password: inads
Login: support Password: supportpw
Login: bans Password: bcms
Login: bcms Password: bcmpw
Login: bcnas Password: bcnspw
Login: bcim Password: bcimpw
Login: bciim Password: bciimpw
Login: bcnas Password: bcnspw
Login: craft Password: craftpw
Login: blue Password: bluepw
Login: field Password: support
Login: kraft Password: kraftpw
Login: nms Password: nmspw

Защита сети РВХ средствами АСЕ-сервера

Если вам встретится система, приглашение которой имеет следующий вид, — не стоит ломать копья: вероятнее всего, такую систему не удастся взломать, поскольку она защищена надежным механизмом на базе протокола АСЕ-сервера.

XX-Feb-XX 02:04:56 *91ХХХ5551234 С: CONNECT 9600/ARQ/V32/LAPM
Hello
Password :
89324123 :
Hello
Password :
65872901 :

Контрмеры против взлома систем РВХ

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

Прямой взлом систем голосовой почты

В начале 90-х годов появились две программы, предназначенные для взлома систем голосовой почты: Voicemail Box Hacker 3.0 и VrACK 0.51. Авторы этой книги пробовали пользоваться ими, но оказалось, что эти программы подходят для взлома более ранних и менее защищенных систем голосовой почты. Программа Voicemail Box Hacker 3.0 предназначена только для работы с системами, использующими четырехзначные пароли. Программа VrACK 0.51 обладает некоторыми интересными возможностями, однако для нее сложно писать сценарии и, вообще, она рассчитана на старые архитектуры компьютеров на базе процессоров х86, а на современных компьютерах работает нестабильно. Возможно, упомянутые программы в настоящее время не поддерживаются потому, что попытки взлома систем голосовой почты предпринимаются нечасто. Таким образом, для взлома систем голосовой почты лучше всего использовать язык сценариев ASPECT.
Сценарий взлома систем голосовой почты аналогичен сценарию взлома удаленных соединений, но основывается на другом принципе. В данном случае достаточно просто установить связь, а попытки регистрации не требуются. Такой сценарий можно реализовать даже вручную, но тогда поиск ограничится лишь последовательным перебором достаточно простых паролей и их комбинаций, которые могут использоваться в системах голосовой почты.
Чтобы взломать систему голосовой почты вручную или с помощью простого сценария перебора паролей (здесь социальная инженерия не потребуется), необходимо знать основной номер для доступа к самой системе голосовой почты, код доступа к нужному почтовому ящику, включая количество цифр (обычно это 3, 4 или 5), а также иметь разумные предположения относительно минимальной и максимальной длины пароля почтового ящика. В большинстве современных систем используются стандартные предельные значения длины пароля, а также типичные предлагаемые по умолчанию пароли. Только очень беспечные компании не пытаются принять хоть какие-то меры защиты систем голосовой почты, однако, как показывает опыт, встречаются и такие. Однако при написании сценария будем исходить из предположения, что организация предпринимает некоторые меры защиты, и ящики голосовой почты имеют пароли.
Сценарий взлома системы голосовой почты должен выглядеть примерно так, как в листинге 9.7. Сценарий в этом примере устанавливает соединение с системой голосовой почты, ожидает приветственного сообщения от автоответчика, например "Вас приветствует система голосовой почты компании X. Назовите, пожалуйста, номер почтового ящика", вводит номер почтового ящика, символ # для подтверждения окончания ввода, вводит пароль и символ подтверждения, а затем снова возобновляет попытку соединения. В этом примере проверяется шесть паролей для почтового ящика 5019. С помощью несложных приемов программирования можно легко написать сценарий, который последовательно выбирает пароли из некоторого словаря. Возможно, этот сценарий, придется подстраивать под конкретный модем. Да и вообще, один и тот же сценарий может отлично работать в одной системе и неудовлетворительно в другой. Поэтому необходимо внимательно следить за его работой. Протестировав сценарий на небольшом перечне паролей, можно запускать его для более объемного словаря.
Листинг 9.7. Простой сценарий взлома системы голосовой почты на языке ASPECT для Procomm Plus

proc main
transmit "atdt*918005551212,,,,, 5019#,111111*,,50191,2222221,,"
transmit "^M"
WAITQUIET 37 HANGUP
transmit "atdt*918005551212,,,,,5019#,333333#,,5019#,555555#,,"
transmit "^м"
WAITQUIET 37 HANGUP
transmit "atdt*918005551212,,,,,5019#,666666*,,5019#,7777771,,"
transmit "^M"
WAITQUIET 37
HANGUP
endproc

Таблица 9.1. Типичные пароли системы Voicemail

Контрмеры против взлома систем голосовой почты

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

Хакинг виртуальных частных сетей

Телефонные сети являются достаточно надежными и разветвленными, поэтому удаленные соединения еще долго не выйдут из обращения. Тем не менее, им на смену уже приходят новые механизмы удаленного доступа — виртуальные частные сети  VPN (Virtual Private Network).
Понятие виртуальной частной сети выходит за рамки отдельной технологии ил;; протокола, однако практически такие сети обеспечивают передачу (туннелирование) частных данных через Internet с использованием дополнительного шифрования. Основными преимуществами сетей VPN являются экономичность и удобство. При использовании существующих каналов связи Internet для создания удаленного офиса, общения с удаленными пользователями и даже удаленными партнерами, сложность сетевой инфраструктуры резко снижается.
Виртуальную частную сеть можно организовать разными способами, начиная от использования защищенного протокола SSH, созданного в рамках модели открытого кода (Open Source Software) и заканчивая такими "собственническими" методами, как FWZ Encapsulation от компании CheckPoint Software (который будет описан ниже). Для организации VPN чаще всего применяется два следующих стандарта: протоколы IPSec (IP Security) и L2TP (Layer 2 Tunneling Protocol), пришедшие на смену более ранним версиям протоколов РРТР (Point-to-Point Tunneling Protocol) и L2F (Layer 2 Forwarding). Техническое описание этих достаточно сложных технологии не является задачей этой книги. Интересующиеся читатели могут обратиться за дополнительной информацией по адресу http: //www. letf .org.
Термин туннелирование (tunneling) подразумевает инкапсуляцию одной (возможно зашифрованной) дейтаграммы в другой, например IP в IP (IPSec) или РРР в OKh (РРТР) Принцип туннелирования проиллюстрирован на рис. 9.7, где изображена виртуальная частная сеть между точками А и В (которые могут представлять собой как отдельные узлы так и целые сети). В передает пакет А (по адресу назначения "А ) через шлюз GW2 (Gateway 2), который может быть программно реализован в В. Шлюз GW2 выполняет инкапсуляцию этого пакета в другой и направляет вновь сформированный пакет шлюзу GW1. Шлюз GW1 удаляет временный заголовок и отправляет исходный пакет в место назначения А. При передаче через Internet исходный пакет может быть дополнительно зашифрован (пунктирная линия на рисунке).
Технологии виртуальных частных сетей за последние несколько лет прошли хорошую практическую проверку и надежно утвердились в архитектурах открытых и частных сетей Многие провайдеры в настоящее время предоставляют услуги по организации виртуальных частных сетей для тех пользователей, которые не хотят создавать их сами. Вполне возможно, что в скором времени виртуальные частные сети полностью вытеснят обычные телефонные соединения в области удаленных коммуникаций. Однако такая популярность технологии VPN обращает на себя все более пристальное внимание хакеров, жаждущих новой добычи в изменяющихся условиях. Как виртуальные частные сети смогут противостоять такой угрозе? Рассмотрим несколько примеров.

Рис. 9.7. Туннелирование одного трафика в другом — основной принцип работы виртуальных частных сетей

Взлом протокола РРТР, реализованного компанией Microsoft

Анализ протокола РРТР в реализации компании Microsoft был выполнен 1 июня 1998 года известным криптоаналитиком Брюсом Шнеером (Bruce Schneier) и знаменитым хакером Питером Маджем (Peter Mudge) (http://www.counterpane.com/pptp. html). Технический обзор результатов этого анализа, представленный Алефом Ваном (Aleph One) для журнала Phrack Magazine. В своем обзоре Алеф Ван вскрыл новые бреши в защите протокола РРТР, в том числе возможности обмана РРТР-сервера с целью получения данных аутентификации. Информацию об устранении недостатков в реализации протокола РРТР от компании Microsoft можно найти по адресу http://www.counterpane.com/ pptpv2-paper.html.
Хотя указанная выше статья касается лишь реализации протокола РРТР компанией Microsoft, из нее можно извлечь полезные уроки относительно виртуальных частных сетей в целом. Поскольку технология виртуальных частных сетей призвана обеспечить дополнительную защиту информации, ее пользователи не подвергают никаким сомнениям возможности этой защиты. Поэтому статья Шнеера и Маджа должна послужить тревожным сигналом для таких беспечных пользователей. Рассмотрим некоторые вопросы, затронутые в этой статье.
Приступая к чтению статьи Шнеера и Маджа, необходимо принимать во внимание сделанные ими допущения и имеющуюся среду для тестирования. Они изучали вопросы взаимодействия клиент/сервер на основе протокола РРТР, а не используемую шлюзами архитектуру сервер/сервер. Клиент, согласно их предположениям, подключался непосредственно к Internet, минуя удаленное соединение. Более того, некоторые из предлагаемых ими атак основываются на возможности беспрепятственного прослушивания сеанса РРТР. И хотя ни одно из сделанных предположений принципиально не влияет на полученные заключения, необходимо понимать, что требование свободного прослушивания сеансов таких коммуникаций само по себе является достаточно жестким и обеспечивает достаточную защиту соединения.
Основные выводы статьи сводятся к следующему.

•  Протокол безопасной аутентификации MS-CHAP компании Microsoft основывается на устаревших криптографических функциях (недостатки хэш-кодов LanManager и соответствующие программы взлома описаны в главе 5).
•  Ключи сеансов, применяемые для шифрования передаваемых по сети данных, основываются на паролях пользователей, следовательно, практическая длина ключей снижается до 40 и 128 битов.
•  Выбранный алгоритм шифрования данных сеанса (симметрический алгоритм RC4) значительно ослабляется за счет повторного применения ключей сеанса в направлениях отправителя и получателя, создавая опасность реализации стандартной криптографической атаки.
•  Канал управления (TCP-порт 1723) для управляющих соединений не использует аутентификацию и абсолютно не защищен от атак, направленных на генерацию события DoS.
•  Кодируются только сами данные, при этом злоумышленники могут свободно извлекать информацию из служебного трафика, передаваемого по каналу управления
•  В статье делается предположение о том, что клиентные подключения к сети,через РРТР-серверы могут служить в качестве потайных входов в эти сети

Устранение недостатков протокол а РРТР

Означает ли все это, что над технологией виртуальных частных сетей разверзлись небеса? Абсолютно нет. Повторим еще раз, что все перечисленные недостатки касаются лишь конкретной реализации протокола компании Microsoft. Все они были устранены в сервисном пакете Service Pack 4 для серверов и клиентов. Более подробная информация об устраненных недостатках содержится в бюллетене Microsoft Security Bulletin MS98-012. Кроме того, в реализации для Windows 2000 протокол РРТР был существенно доработан. Теперь существует возможность использования протокола L2TP, основанного на IPSec. Для совместимости с новыми средствами обеспечения безопасности со стороны серверов РРТР-клиенты, работающие под управлением Win 9x, необходимо модернизировать с помощью Dial-Up Networking версии 1.3. Компания Microsoft подготовила подробный документ, касающийся протокола РРТР и защиты виртуальных частных сетей, который можно найти по адресу  http://www.microsoft.com/ntserver/zipdocs/vpnsecur.exe).

В ответ на предпринятые компанией Microsoft действия Шнеер и Мадж опубликовали новую статью, в которой одобрили результаты устранения большинства из описанных ранее недостатков. Однако авторы замечают, что протокол MS РРТР по-прежнему основывается на пользовательских паролях в целях обеспечения разнообразия ключей.