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

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

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

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

В протоколе TCP данный уровень защиты является стандартным. Он встроен в протокол в виде трехэтапного установления соединения. По существу трехэтапное установление соединения выглядит следующим образом. «Здравствуйте, я – Боб». «А я Алиса. Вы говорите, что Вы – Боб?» «Да, Алиса, я – Боб». Если Боб сообщает Алисе: «Да, Алиса, я – Боб», а Алиса перед этим с Бобом не разговаривала, то протокол может решить, что имеет место атака спуфинга вслепую (blind spoofing). (В действительности протоколы редко ищут случаи нападения. Скорее они функционируют только при отсутствии нападений. Это происходит из-за того, что большинство протоколов предназначены для установления соединения, а не для отражения атаки. В результате это приводит к невозможности работы по протоколу из-за аварийного завершения его функций, за исключением случаев обработки данных, предусмотренных протоколом. В итоге протоколы повышают уровень своей безопасности простым способом: значительно сокращают число хостов, которые могли бы легко атаковать их. Простое сокращение числа хостов, которые могли бы осуществить прямое нападение «с любой машины в Интернете» на «любую машину Интернета при наличии десятка подсетей между сервером и клиентом» часто на многие порядки сокращает число хостов, способных к эффективной атаке!)

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

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

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

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

При сканировании вслепую исследуемый хост должен как-то знать о получении зомби его положительных ответов. Антирез (Antirez) обнаружил способ узнать об этом, который был реализован хакером Федором (Fyodor) при построении сетевых схем nmap в виде опции —si. В открытом Антирезом (Antirez) способе используется поле IPID. На уровне протокола IP поле IPID позволяет одному пакету ссылаться на другой, устанавливая тем самым ссылки на фрагментированные пакеты. Во многих операционных системах поле IPID после отправки каждого пакета увеличивается на l. (В операционной системе Windows приращение значения поля IPID происходит в соответствии с прямым порядком байтов (little-endian). Прямой порядок байтов – формат хранения и передачи двоичных данных, при котором сначала (первым) передается младший (наименее значимый) бит (байт). Поэтому на самом деле значение поля увеличивается на 256. Но на суть способа это не влияет.) В протоколе TCP предусмотрено, что при положительном ответе хоста на запрос установления соединения по указанному порту (получении сообщения c установленным в заголовке пакета флажком SYN – пакета SYN) он возвращает сообщение с установленными в заголовке пакета флажками подтверждения запроса на установления соединения SYN и ACK – пакета SYNIACK. Но когда зомби, который никогда не пытался соединиться с кем-либо, получает пакет SYNIACK, то он сообщает отправителю пакета о завершении сеанса связи с ним и завершает соединение. Это выполняется при помощи посылки пакета, в заголовке которого установлены флажки RST и ACK – пакета RSTIACK. В рамках подобной передачи никакие данные больше не пересылаются. Атакуемый хост посылает зомби пакет RSTIACK, если порт закрыт, а зомби ничего не присылает в ответ.

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

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

Сканирование вслепую тривиально осуществить при помощи nmap. Достаточно в командной строке указать опцию – sI zombie_host: port target: port и ждать. Более подробные сведения можно найти по адресу www.bursztein.net/secu/temoinus.html.

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

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

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

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

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

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

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

• возможность удалять некоторые или все необработанные биты данных либо пакеты в зависимости от их содержания. Выборочное удаление данных реализовать сложнее модуляции, потому что получаемый при этом сигнал будет рассинхронизирован со своим оригиналом. Изохронному потоку данных (потоку данных с одинаковой скоростью передачи) требуется задержка для предотвращения передачи ложных указателей. (Нужно что-то послать, не так ли? Спертый воздух и будет этим чем-то.)

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

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

Так что это за переменная?

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

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

Относительно разговора о спуфинге протокола IP. TCP/IP – это стек (набор) протоколов, и протокол IP – один из них, причем он требует поддержки. Для защиты протокола IP от спуфинга следует использовать протоколы (подобные протоколу TCP), в которых при инициализации соединения предусмотрен обязательный ответ и которые могут лишить возможности передачи, бесцеремонно сбрасывая полученные данные в битоприемник (bit bucket) (это гипотетическая корзина, в которую сбрасываются «мусорные» записи базы данных), тем самым защищая сеть от входящих и выходящих пакетов, относительно содержимого которых появилось подозрение, что оно фальсифицировано отправителем пакета.

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

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

Для общедоступных сервисов это очень важный вопрос.

В большинстве случаев Интернет обслуживает внутренние потоки данных, не тревожа своих клиентов. Доказательство их подлинности может быть сведено к одному запросу HTTP с методом GET/. (В данном случае точка является знаком препинания, завершающим предложение, а не ссылкой слэш-точка. Обязательная ссылка слэш-точка в тексте выделяется курсивом.)

Описанный в RFCl945 метод запроса GET протокола HTTP известен многим. Есть возможность реализовать аутентификацию на более высоких уровнях, если они поддерживаются этим протоколом. Причем их модернизация может быть выполнена в достаточно мягкой форме. В основном доступ к системе зависит от знания протокола HTTP и возможности установить успешное соединение по протоколу TCP c использованием его стандартного порта 80.

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

К сожалению, это не означает, что любой захочет связаться с системой.

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

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

Кто допустил эту ошибку?

Эту ошибку допустили Microsoft и Novell одновременно. Клиентские программы обеих компаний (возможно, исключая сети Windows 2000 с поддержкой технологии аутентификации и шифрования с открытым ключом Kerberos) после подключения не предусматривают какой-либо аутентификации в доменах, через которые они вошли в систему. В действительности домены, работающие с клиентскими программами названных компаний, могут только сказать: «Добро пожаловать в мой домен. Вот для вас сценарий команд, который вы сможете выполнить после подключения». В основе сказанного лежит предположение, что всякий, кто когда-либо подключился к локальной вычислительной сети, является ее законным пользователем. При этом полагается, что физическая безопасность офиса (вероятно, то место, где находится локальная вычислительная сеть) способна предотвратить появление фальсифицированных сервисов. Вот что автор писал в мае l999 года: