Крис Касперский - ТЕХНИКА СЕТЕВЫХ АТАК Страница 7

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

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

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

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

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

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

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

Съел бобра - спас дерево!

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

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

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

Примером протокола может случить командный язык интерпретатора “command.com”. С его помощью пользователь может управлять файлами и папками своего компьютера. Если попытаться применить ту же схему для взаимодействия с удаленным сервером возникнет необходимость добавить в протокол механизмы установки и управления связью.

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

Причем один язык ничего не знал о существовании другого, - это обеспечивало полную взаимную независимость. В самом деле, для получения файла с сервера достаточно отдать команду “«Получить Файл» («Имя Файла»)”, совершенно не интересуясь, как и чем было создано соединение между двумя компьютерами, - достаточно лишь знать, что оно есть и все.

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

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

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

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

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

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

Пожалуй, начнем…

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

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

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

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

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

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

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