Этот раздел содержит краткое описание TCP/IP в объеме, достаточном для последующего обсуждения проблем безопасности, связанных с Интернетом. [Com91a],[Com91b],[Hunt92] и [Bel89] содержат гораздо более подробное описание; читатели, которые хотят получить более глубокое представление, должны обратиться к этим источникам.
Отчасти популярность стека протоколов TCP/IP объясняется возможностью его реализации на базе большого числа разнообразных каналов и протоколов канального уровня, таких как T1 и Х.25, Ethernet и линии RS-232. Большинство организаций использует в своих ЛВС Ethernet для объединения хостов и клиентских систем, а затем присоединяет эти сети с помощью T1 к региональной сети. (например, региональной магистральной сети TCP/IP), которая соединяет в свою очередь с сетями других организаций и другими магистральными каналами. Как правило, организации имеют одно соединение с Интернетом, но большие организации могут иметь два и более соединений. Скорости модемов увеличиваются по мере появления новых коммуникационных стандартов, поэтому версии TCP/IP, которые работают в среде коммутируемых телефонных каналов, становятся все более популярными. Многие организации и просто отдельные люди используют PPP (Point-to-Point Protocol) и SLIP (Serial Line IP) для подключения своих сетей и рабочих станций к другим сетям, используя телефонные каналы.
Если говорить строго, то TCP/IP - это стек протоколов, включающий TCP, IP, UDP (User Datagram Protocol), ICMP (Internet Control Message Protocol), и ряд других протоколов. Стек протоколов TCP/IP не соответствует модели взаимодействия открытых систем (ВОС), и его структура показана на рисунке 1.1
Уровень IP получает пакеты, доставлемые нижними уровнями, например драйвером интерфейса с ЛВС, и передает их лежащим выше уровням TCP или UDP. И наоборот, IP передает пакеты, полученные от уровней TCP и UDP к нижележащим уровням.
Пакеты IP являются дейтаграмами с негарантированной доставкой, потому что IP ничего не делает для обеспечения гарантии доставки пакетов IP по порядку и без ошибок. Пакеты IP содержат адрес хоста, с которого был послан пакет, называемый адресом отправителя, и адрес хоста, который должен получить пакет, называемый адресом получателя.
Высокоуровневые сервисы TCP и UDP при приеме пакета предполагают, что адрес отправителя, указанный в пакете, является истинным. Другими словами, адрес IP является основой для аутентификации во многих сервисах; сервисы предполагают, что пакет был послан от существующего хоста, и именно от того хоста, чей адрес указан в пакете. IP имеет опцию, называемую опция маршрутизации источника, которая может быть использована для для указания точного прямого и обратного пути между отправителем и получателем. Этот путь может задействовать для передачи пакета маршрутизаторы или хосты, обычно не использующиеся для передачи пакетов к данному хосту-получателю. Для некоторых сервисов TCP и UDP пакет IP c такой опцией кажется пришедшим от последней системы в указанном пути, а не от своего истинного отправителя. Эта опция появилась в протоколе для его тестирования, но [Bel89] отмечает, что маршрутизация источника может использоваться для обмана систем с целью установления соединения с ними тех хостов, которым запрещено с ними соединяться. Поэтому, то, что ряд сервисов доверяют указанному IP-адресу отправителя и полагаются на него при аутентификации, очень опасно и может привести к проникновению в систему.
Если IP-пакеты содержат инкапсулированные пакеты TCP, программы IP передадут их вверх уровню TCP. TCP последовательно нумерует все пакеты и выполняет исправление ошибок, и реализует таким образом виртуальные соединения между хостами. Пакеты TCP содержат последовательные номера и подтверждения о приеме пакетов, поэтому пакеты, принятые не в порядке передачи, могут быть переупорядочены , а испорченные пакеты повторно посланы.
TCP передает полученную информацию приложениям верхнего уровня, например клиенту или серверу TELNETа. Приложения, в свою очередь, передают информацию обратно уровню TCP, который передает ее ниже уровню IP, после чего она попадает к драйверам устройств, в физическую среду и по ней передается до хоста-получателя. Сервисы с установлением соединения, такие как TELNET, FTP, rlogin, X Windows и SMTP требуют надежности и поэтому используют TCP. DNS использует TCP только в ряде случаев( для передачи и приема баз данных доменных имен), а для передачи информации об отдельных хостах использует UDP .
Как показано на рисунке 1.1, UDP взаимодействует с прикладными программами на том же уровне, что и TCP. Тем не менее, он не выполняет функции исправления ошибок или повторной передачи потерянных пакетов. Поэтому UDP не используется в сервисах с установлением соединения, которым требуется создание виртуального канала. Он применяется в сервисах типа запрос-ответ, таких как NFS, где число сообщений в ходе взаимодействия гораздо меньше, чем в TELNET и FTP. В число сервисов, использующих UDP, входят сервисы на базе RPC, такие как NIS и NFS, NTP( протокол сетевого времени) и DNS(также DNS использует TCP).
Пакеты UDP гораздо проще подделать, чем пакеты TCP, так как нет этапа установления соединения( рукопожатия).[Ches94]. Поэтому с использованием сервисов на базе UDP сопряжен больший риск.
ICMP (Протокол межсетевых управляющих сообщений) находится на том же уровне, что и IP; его назначение - передавать информацию, требуемую для управления траффиком IP. В-основном, он используется для предоставления информации о путях к хостам-получателям. Сообщения ICMP redirect информируют хосты о существовании боле коротких маршрутов к другим системам, а сообщения ICMP unreachable указывает на наличие проблем с нахождением пути к получателю пакета. Кроме того, ICMP может помочь корректно завершить соединение TCP, если путь стал недоступен. PING является широко распространенным сервисом на базе ICMP.
[Bel89] рассматривает две проблемы с ICMP: старые версии Unix могут разорвать все соединения между хостами, даже если только одно из них столкнулось с проблемами. Кроме того, сообщения о перенаправлении пути ICMP могут быть использованы для обмана маршрутизаторов и хостов с целью заставить их поверить в то, что хост злоумышленника является маршрутизатором и пакеты лучше отправлять через него. Это, в свою очередь, может привести к тому, что атакующий получит доступ к системам, которым не разрешено иметь соединения с машиной атакующего или его сетью.
Сервисы TCP и UDP используются с помощью схемы клиент-сервер. Например, процесс сервера TELNET вначале находится в состоянии ожидания запроса установления соединения. В какой-нибудь момент времени пользователь запускает процесс клиента TELNET, который инициирует соединение с сервером TELNET. Клиент посылает данные серверу, тот читает их, и посылает обратно клиенту ответ. Клиент читает ответ и сообщает о нем пользователю. Поэтому, соединение является двунаправленным и может быть использовано как для чтения, так и для записи.
Как много одновременных соединений TELNET может быть установлено между системами? Соединение TCP или UDP уникальным образом идентифицируется с помощью четырех полей, присутствующих в каждом соединении:
Порт - это программное понятие, которое используется клиентом или сервером для посылки или приема сообщений; порт идентифицируется 16-битвым числом. Серверные процессы обычно ассоциируются с фиксированным числом, например числом 25 для SMTP или 6000 для X Windows; номер порта является известным, так как он требуется, помимо IP-адреса получателя, при установлении соединения с конкретным хостом и сервисом. Клиентские процессы, с другой стороны, запрашивают номер порта у операционной системы в начале работы; и номер порта является случайным, хотя в некоторых случаях он является следующим в списке свободных номеров портов.
Для иллюстрации того, как используются порты для посылки и приема сообщений, рассмотрим протокол TELNET. Сервер TELNET слушает приходящие сообщения на порту 23, и сам посылает сообщения на порт 23. Клиент TELNET, на той же или другой системе, сначала запрашивает неиспользуемый номер порта у ОС, а затем использует его при посылке и приеме сообщений. Он должен указывать это номер порта, например 3097, в пакетах, предназначенных для сервера TELNET, чтобы этот сервер при ответе на сообщение клиента мог поместить это номер в посылаемые им TCP-пакеты. Хост клиента по приему сообщения должен посмотреть номер порта в сообщении и решить, какой из клиентов TELNET должен принять это сообщение. Этот процесс показан на рисунке 1.2
Рисунок 1.2 Взаимодействие при TELNET
Существует достаточно распространенное правило, согласно которому тольуо привилегированные процессы сервера, то есть те процессы, которые работают с привилегиями суперпользователя UNIX, могут использовать порты с номерами меньше, чем 1024( так называемые привилегированные порты). Сервера в-основном используют порты с номерами меньше, чем 1024, а клиенты как правило должны запрашивать непривилегированные порты у ОС. Хотя это правило и не является обязательным для исполнения и не требуется спецификацией протоколов TCP/IP, системы на основе BSD соблюдают его.
В результате всего этого брандмауэры могут блокировать или фильтровать доступ к службам на основе проверки номеров портов в TCP- и UDP-пакетах и последующего пропускания через себя или удаления пакета на основе политики, указывающей доступ к каким службам разрешен или запрещен. (более детально это описано в главе 2).
Не все серверы и клиенты TCP и UDP используют порты таким простым способом, как TELNET, но в целом, процедура, описанная здесь, полезна в контексте брандмауэра. Например, многие ОС персональных компьютеров не используют понятия суперпользователя UNIX, но все-таки используют порты описанным выше способом( хотя нет стандарта, требующего это).
Назад | Содержание | Вперед
|
|
 |
