Вход
Регистрация
Помощь
ВОТ ОЛЕНИ!!!! Мы проиграли 
FC Bayern München против FC Chelsea
Протоколы семейства IP являются основой построения сетей intranet и глобальной сети Internet. Несмотря на то, что разработка TCP/IP финансировалась Министерством обороны США, TCP/IP не обладает абсолютной защищенностью и допускает различные типы атак, рассмотренные в данной статье. Для того, чтобы предпринять подобные атаки, крэкер должен обладать контролем над одной из систем, подключенной к Internet. Это возможно, например, в случае, когда крэкер взломал какую-то систему или использует собственный компьютер, имеющий соединение с Internet (для многих атак достаточно иметь PPP-доступ). В данной статье не рассматриваются возможные физические атаки (например, непосредственный съем информации через ethernet или перехват трафика между радио-мостами). Все внимание обращено на программную реализацию. Статья подразумевает знакомство читателя с TCP/IP и ориентирована на администраторов в области безопасности. Официальное описание семейства IP-протоколов можно найти в RFC, при первом знакомстве с TCP/IP может оказать неоценимую помощь великолепная книга "TCP/IP Illustrated" by R.Stevens. Автор оставляет в стороне моральные вопросы, т.к. считает, что только полная информация может помочь подготовиться к возможным атакам и защититься от них. Принцип "Безопасность через незнание" (Security through Obscurity) редко оправдывает себя. Атаки на TCP/IP можно разделить на два вида: пассивные и активные.
Пассивные атаки на уровне TCP
При данном типе атак крэкеры никаким образом не обнаруживают себя и не вступают напрямую во взаимодействие с другими системами. Фактически все сводиться к наблюдению за доступными данными или сессиями связи.
Подслушивание
Атака заключаются в перехвате сетевого потока и его анализе (от англ. "sniffing"). Для осуществления подслушивания крэкеру необходимо иметь доступ к машине, расположенной на пути сетевого потока, который необходимо анализировать; например, к маршрутизатору или PPP-серверу на базе UNIX. Если крэкеру удастся получить достаточные права на этой машине, то с помощью специального программного обеспечения сможет просматривать весь трафик, проходящий через заданные интерфейс. Второй вариант -- крэкер получает доступ к машине, которая расположена в одном сегменте сети с системой, которой имеет доступ к сетевому потоку. Например, в сети "тонкий ethernet" сетевая карта может быть переведена в режим, в котором она будет получать все пакеты, циркулирующие по сети, а не только адресованной ей конкретно. В данном случае крэкеру не требуется доступ к UNIX -- достаточно иметь PC с DOS или Windows (частая ситуация в университетских сетях). Поскольку TCP/IP-трафик, как правило, не шифруется (мы рассмотрим исключения ниже), крэкер, используя соответствующий инструментарий, может перехватывать TCP/IP-пакеты, например, telnet-сессий и извлекать из них имена пользователей и их пароли. Следует заметить, что данный тип атаки невозможно отследить, не обладая доступом к системе крэкера, поскольку сетевой поток не изменяется. Единственная надежная защита от подслушивания -- шифрование TCP/IP-потока (например, secure shell) или использование одноразовых паролей (например, S/KEY). Другой вариант решения - использование интеллектуальных свитчей и UTP, в результате чего каждая машина получает только тот трафик, что адресован ей. У каждой палки два конца. Естественно, подслушивание может быть и полезно. Так, данный метод используется большим количеством программ, помогающих администраторам в анализе работы сети (ее загруженности, работоспособности и т.д.). Один из ярких примеров -- общеизвестный tcpdump.
Активные атаки на уровне TCP
При данном типе атак крэкер взаимодействует с получателем информации, отправителем и/или промежуточными системами, возможно, модифицируя и/или фильтруя содержимое TCP/IP-пакетов. Данные типы атак часто кажутся технически сложными в реализации, однако для хорошего программиста не составляет труда реализовать соотвествующий инструментарий. К сожалению, сейчас такие программы стали доступны широким массам пользователей (например, см. раздел про SYN-затопление). Активные атаки можно разделить на две части. В первом случае крэкер предпринимает определенные шаги для перехвата и модификации сетевого потока или попыток "притвориться" другой системой. Во втором случае протокол TCP/IP используется для того, чтобы привести систему-жертву в нерабочее состоянии. Обладая достаточными привилегиями в Unix (или попросту используя DOS или Windows, не имеющие системы ограничений пользователей), крэкер может вручную формировать IP-пакеты и передавать их по сети. Естественно, поля заголовка пакета могут быть сформированы произвольным образом. Получив такой пакет, невозможно выяснить откуда реально он был получен, поскольку пакеты не содержат пути их прохождения. Конечно, при установке обратного адреса не совпадающим с текущим IP-адресом, крэкер никогда не получит ответ на отосланный пакет. Однако, как мы увидим, часто это и не требуется. Возможность формирования произвольных IP-пакетов является ключевым пунктом для осуществления активных атак.
Предсказание TCP sequence number
Данная атака была описана еще Робертом Моррисом (Robert T. Morris) в A Weakness in the 4.2BSD Unix TCP/IP Software Англоязычный термин -- IP spoofing. В данном случае цель крэкера - притвориться другой системой, которой, например, "доверяет" система-жертва (в случае использования протокола rlogin/rsh для беспарольного входа). Метод также используется для других целей -- например, для использовании SMTP жертвы для посылки поддельных писем.
Описание
Вспомним, что установка TCP-соединения происходит в три стадии (3-way handshake): клиент выбирает и передает серверу sequence number (назовем его C-SYN), в ответ на это сервер высылает клиенту пакет данных, содержащий подтверждение (C-ACK) и собственный sequence number сервера (S-SYN). Теперь уже клиент должен выслать подтверждение (S-ACK). Схематично это можно представить так: После этого соединение считается установленным и начинается обмен данными. При этом каждый пакет имеет в заголовке поле для sequence number и acknowledge number. Данные числа увеличиваются при обмене данными и позволяют контролировать корректность передачи. Предположим, что крэкер может предсказать, какой sequence number (S-SYN по схеме) будет выслан сервером. Это возможно сделать на основе знаний о конкретной реализации TCP/IP. Например, в 4.3BSD значение sequence number, которое будет использовано при установке следующего значения, каждую секунду увеличивается на 125000. Таким образом, послав один пакет серверу, крэкер получит ответ и сможет (возможно, с нескольких попыткок и с поправкой на скорость соединения) предсказать sequence number для следующего соединения. Если реализация TCP/IP использует специальный алгоритм для определения sequence number, то он может быть выяснен с помощью посылки нескольких десятков пакетов серверу и анализа его ответов. Итак, предположим, что система A доверяет системе B, так, что пользователь системы B может сделать "rlogin A"_ и оказаться на A, не вводя пароля. Предположим, что крэкер расположен на системе C. Система A выступает в роли сервера, системы B и C - в роли клиентов. Первая задача крэкера - ввести систему B в состояние, когда она не сможет отвечать на сетевые запросы. Это может быть сделано несколькими способами, в простейшем случае нужно просто дождаться перезагрузки системы B. Нескольких минут, в течении которых она будет неработоспособна, должно хватить. Другой вариант -- использование описанными в следующих разделах методов. После этого крэкер может попробовать притвориться системой B, для того, что бы получить доступ к системе A (хотя бы кратковременный).
Крэкер высылает несколько IP-пакетов, инициирующих соединение, системе A, для выяснения текущего состояния sequence number сервера.
Крэкер высылает IP-пакет, в котором в качестве обратного адреса указан уже адрес системы B.
Система A отвечает пакетом с sequence number, который направляется системе B. Однако система B никогда не получит его (она выведена из строя), как, впрочем, и крэкер. Но он на основе предыдущего анализа догадывается, какой sequence number был выслан системе B.
Крэкер подтверждает "получение" пакета от A, выслав от имени B пакет с предполагаемым S-ACK(заметим, что если системы располагаются в одном сегменте, крэкеру для выяснения sequence number достаточно перехватить пакет, посланный системой A).
После этого, если крэкеру повезло и sequence number сервера был угадан верно, соединение считается установленным. Теперь крэкер может выслать очередной фальшивый IP-пакет, который будет уже содержать данные. Например, если атака была направлена на rsh, он может содержать команды создания файла .rhosts или отправки /etc/passwd крэкеру по электронной почте.
Детектирование и защита
Простейшим сигналом IP-spoofing будут служить пакеты с внутренними адресами, пришедшие из внешнего мира. Программное обеспечение маршрутизатора может предупредить об этом администратора. Однако не стоит обольщаться - атака может быть и изнутри Вашей сети. В случае использования более интеллектуальных средств контроля за сетью администратор может отслеживать (в автоматическом режиме) пакеты от систем, которые в находятся в недоступном состоянии. Впрочем, что мешает крэкеру имитировать работу системы B ответом на ICMP-пакеты? Какие способы существуют для защиты от IP-spoofing? Во-первых, можно усложнить или сделать невозможным угадывание sequence number (ключевой элемент атаки). Например, можно увеличить скорость изменения sequence number на сервере или выбирать коэффициент увеличения sequence number случайно (желательно, используя для генерации случайных чисел криптографически стойкий алгоритм). Если сеть использует firewall (или другой фильтр IP-пакетов), следует добавить ему правила, по которым все пакеты, пришедшие извне и имеющие обратными адресами из нашего адресного пространства, не должны пропускаться внутрь сети. Кроме того, следует минимизировать доверие машин друг другу. В идеале не должны существовать способа, напрямую попасть на соседнюю машину сети, получив права суперпользователя на одной из них. Конечно, это не спасет от использования сервисов, не требующих авторизации, например, IRC (крэкер может притвориться произвольной машиной Internet и передать набор команд для входа на канал IRC, выдачи произвольных сообщений и т.д.). Шифрование TCP/IP-потока решает в общем случае проблему IP-spoofing`а (при условии, что используются криптографически стойкие алгоритмы). Для того, чтобы уменьший число таких атак, рекомендуется также настроить firewall для фильтрации пакетов, посланных нашей сетью наружу, но имеющих адреса, не принадлежащие нашему адресному пространству. Это защитит мир от атак из внутренней сети, кроме того, детектирование подобных пакетов будет означать нарушение внутренней безопасности и может помочь администратору в работе.
IP Hijacking
Если в предыдущем случае крэкер инициировал новое соединение, то в данном случае он перехватывает весь сетевой поток, модифицируя его и фильтруя произвольным образом. Метод является комбинацией "подслушивания" и IP spoofing`а.
Описание
Необходимые условия -- крэкер должен иметь доступ к машине, находящейся на пути сетевого потока и обладать достаточными правами на ней для генерации и перехвата IP-пакетов. Напомним, что при передаче данных постоянно используются sequence number и acknowledge number (оба поля находятся в IP-заголовке). Исходя из их значения, сервер и клиент проверяют корректность передачи пакетов. Существует возможность ввести соединение в "десинхронизированное состояние", когда присылаемые сервером sequence number и acknowledge number не будут совпадать с ожидаемым значениеми клиента, и наоборот. В данном случае крэкер, "прослушивая" линию, может взять на себя функции посредника, генерируя корректные пакеты для клиента и сервера и перехватывая их ответы. Метод позволяет полностью обойти такие системы защиты, как, например, одноразовые пароли, поскольку крэкер начинает работу уже после того, как произойдет авторизация пользователя. Есть два способа рассинхронизировать соединение:
Ранняя десинхронизация
Соединение десинхронизируется на стадии его установки.
Крэкер прослушивает сегмент сети, по которому будут проходить пакеты интересующей его сессии.
Дождавшись пакета S-SYN от сервера, крэкер высылает серверу пакет типа RST (сброс), конечно, с корректным sequence number, и, немедленно, вслед за ним фальшивый C-SYN-пакет от имени клиента.
Сервер сбрасывает первую сессию и открывает новую, на том же порту, но уже с новым sequence number, после чего посылает клиенту новый S-SYN-пакет.
Клиент игнорирует S-SYN-пакет, однако крэкер, прослушивающий линию, высылает серверу S-ACK-пакет от имени клиента.
Итак, клиент и сервер находятся в состоянии ESTABLISHED, однако сессия десинхронизирована. Естественно, 100% срабатывания у этой схемы нет, например, она не застрахована от того, что по дороге не потеряются какие-то пакеты, посланные крэкером. Для корректной обработки этих ситуаций программа должна быть усложнена.
Десинхронизация нулевыми данными
В данном случае крэкер прослушивает сессию и в какой-то момент посылает серверу пакет с "нулевыми" данными, т.е. такими, которые фактически будут проигнорированы на уровне прикладной программы и не видны клиенту (например, для telnet это может быть данные типа IAC NOP IAC NOP IAC NOP...). Аналогичный пакет посылается клиенту. Очевидно, что после этого сессия переходит в десинхронизированное состояние.
ACK-буря
Одна из проблем IP Hijacking заключается в том, что любой пакет, высланный в момент, когда сессия находится в десинхронизированном состоянии вызывает так называемый ACK-бурю. Например, пакет выслан сервером, и для клиента он является неприемлимым, поэтому тот отвечает ACK-пакетом. В ответ на этот неприемлимый уже для сервера пакет клиент вновь получает ответ... И так до бесконечности. К счастью (или к сожалению?) современные сети строятся по технологиям, когда допускается потеря отдельных пакетов. Поскольку ACK-пакеты не несут данных, повторных передачи не происходит и "буря стихает". Как показали опыты, чем сильнее ACK-буря, тем быстрее она "утихомиривает" себя - на 10MB ethernet это происходит за доли секунды. На ненадежных соединениях типа SLIP - ненамного больше.
Детектирование и защита
Есть несколько путей. Например, можно реализовать TCP/IP-стэк, которые будут контролировать переход в десинхронизированное состояние, обмениваясь информацией о sequence number/acknowledge number. Однако в данному случае мы не застрахованы от крэкера, меняющего и эти значения. Поэтому более надежным способом является анализ загруженности сети, отслеживание возникающих ACK-бурь. Это можно реализовать при помощи конкретных средств контроля за сетью. Если крэкер не потрудиться поддерживать десинхронизированное соединение до его закрытия или не станет фильтровать вывод своих команд, это также будет сразу замечено пользователем. К сожалению, подавляющее большинство просто откруют новую сессию, не обращаясь к администратору. Стопроцентную защиту от данной атаки обеспечивает, как всегда, шифрование TCP/IP-трафика (на уровне приложений - secure shell) или на уровн протокола - IPsec). Это исключает возможность модификации сетевого потока. Для защиты почтовых сообщений может применяться PGP. Следует заметить, что метод также не срабатывает на некоторых конкретных реализациях TCP/IP. Так, несмотря на [rfc...], который требует молчаливого закрытия сесии в ответ на RST-пакет, некоторые системы генерируют встречный RST-пакет. Это делает невозможным раннюю десинхронизацию. Для более глубокого ознакомления с этой атакой рекомендуется обратиться к IP Hijacking (CERT).
Пассивное сканирование
Сканирование часто применяется крэкерами для того, чтобы выяснить, на каких TCP-портах работают демоны, отвечающие на запросы из сети. Обычная программа-сканер последовательно открывает соединения с различными портами. В случае, когда соединение устанавливается, программа сбрасывает его, сообщая номер порта крэкеру. Данный способ легко детектируются по сообщениям демонов, удивленных мгновенно прерваным после установки соединением, или с помощью использования специальных программ. Лучшие из таких программ обладают некоторыми попытками внести элементы искуственного элемента в отслеживание попыток соединения с различными портами. Однако крэкер может воспользоваться другим методом -- пассивным сканированием (английский термин "passive scan"). При его использовании крэкер посылает TCP/IP SYN-пакет на все порты подряд (или по какому-то заданному алгоритму). Для TCP-портов, принимающих соединения извне, будет возвращен SYN/ACK-пакет, как приглашение продолжить 3-way handshake. Остальные вернут RST-пакеты. Проанализировав данные ответ, крэкер может быстро понять, на каких портах работают программа. В ответ на SYN/ACK-пакеты он может также ответить RST-пакетами, показывая, что процесс установки соединения продолжен не будет (в общем случае RST-пакетами автоматический ответит TCP/IP-реализация крэкера, если он не предпримет специальных мер). Метод не детектируется предыдущими способами, поскольку реальное TCP/IP-соединение не устанавливается. Однако (в зависимости от поведения крэкера) можно отслеживать: резко возросшее количество сессий, находящихся в состоянии SYN_RECEIVED. (при условии, что крэкер не посылает в ответ RST);
прием от клиента RST-пакета в ответ на SYN/ACK.
К сожалению, при достаточно умном поведении крэкера (например, сканирование с низкой скоростью или проверка лишь конкретных портов) детектировать пассивное сканирование невозможно, поскольку оно ничем не отличается от обычных попыток установить соединение. В качестве защиты можно лишь посоветовать закрыть на firewall все сервисы, доступ к которым не требуется извне.
Затопление ICMP-пакетами
Традиционный англоязычный термин -- "ping flood". Появился он потому, что программа "ping", предназначенная для оценки качества линии, имеет ключ для "агрессивного" тестирования. В этом режиме запросы посылаются с максимально возможной скоростью и программа позволяет оценить, как работает сеть при максимальной нагрузке. Данная атака требует от крэкера доступа к быстрым каналам в Интернет. Вспомним, как работает ping. Программа посылает ICMP-пакет типа ECHO REQUEST, выставляя в нем время и его идентификатор. Ядро машины-получателя отвечает на подобный запрос пакетом ICMP ECHO REPLY. Получив его ping выдает скорость прохождения пакета. При стандартном режиме работы пакеты выслаются через некоторые промежутки времени, практически не нагружая сеть. Но в "агрессивном" режиме поток ICMP echo request/reply-пакетов может вызвать перегрузку небольшой линии, лишив ее способности передавать полезную информацию. Естественно, случай с ping является частным случаем более общей ситуации, связанный с перегрузкой каналов. Например, крэкер может посылать множество UDP-пакетов на 19-й порт машины-жертвы, и горе ей, если она, следуя общепринятым правилам, имеет на 19-м UDP-порту знакогенератор, отвечающий на пакеты строчками по 80 байт. Заметим, что крэкер может также подделывать обратный адрес подобных пакетов, затрудняя его обнаружение. Отследить его поможет разве что скоординированная работа специалистов на промежуточных маршрутизаторах, что практически нереально. Одной из вариантов атаки - посылать ICMP echo request-пакеты с исходным адресом, указывающем на жертву, на broadcast-адреса крупных сетей. В результате каждая из машин ответит на этот фальшивый запрос, и машина-отправитель получит больше количество ответов. Посылка множество broadcast-echo requests от имени "жертвы" на broadcast-адреса крупных сетей, можно вызвать резкой заполненение канала "жертвы". Приметы затопления - резко возросшая нагрузка на сеть (или канал) и повышение количество специфических пакетов (таких, как ICMP). В качестве защиты можно порекомендовать настройку маршрутизаторов, при которых они будут фильтровать тот же ICMP трафик, превышающие некоторую заданную заранее величину (пакетов/ед. времени). Для того, чтобы убедиться, что Ваши машины не могут служить источником ping flood`а, ограничьте доступ к ping.
Локальная буря
Сделаем небольшое отступление в сторону реализации TCP/IP и рассмотрим "локальные бури" на пример UDP-бури. Как правило, по умолчанию системы поддерживают работу таких UDP-портов, как 7 ("эхо", полученный пакет отсылается назад), 19 ("знакогенератор", в ответ на полученный пакет отправителю выслается строка знакогенератора) и других (date etc). В данном случае крэкер может послать единственный UDP-пакет, где в качестве исходного порта будет указан 7, в качестве получателя - 19-й, а в качестве адреса получателя и отправителя будут указаны, к примеру, две машины вашей сети (или даже 127.0.0.1). Получив пакет, 19-й порт отвечает строкой, которая попадает на порт 7. Седьмой порт дублирует ее и вновь отсылает на 19.. и так до бесконечности. Бесконечный цикл съедает ресурсы машин и добавляет на канал бессмысленную нагрузку. Конечно, при первом потерянном UDP-пакете буря прекратиться. Как недавно стало известно, данная атака временно выводит из строя (до перезагрузки) некоторые старые модели маршрутизаторов. Очевидно, что в бесконечный разговор могут быть вовлечены многие демоны (в случае TCP/IP может быть применен TCP/IP spoofing, в случае UDP/ICMP достаточно пары фальшивых пакетов). В качестве защиты стоит еще раз порекомендовать не пропускать в сети пакеты с внутренними адресам, но пришедшие извне. Также рекомендуется закрыть на firewall использование большинства сервисов.
Затопление SYN-пакетами
Пожалуй, затопление SYN-пакетами ("SYN flooding") - самый известный способ напакостить ближнему, с того времени, как хакерский электронный журнал "2600" опубликовал исходные тексты программы, позволяющие занятьсе этим даже неквалифицированным пользователям. Следует заметить, что впервые эта атака была упомянута еще в 1986 году все тем же Робертом Т. Моррисом. Вспомним, как работает TCP/IP в случае входящих соединений. Система отвечает на пришедший C-SYN-пакет S-SYN/C-ACK-пакетом, переводит сессию в состояние SYN_RECEIVED и заносит ее в очередь. Если в течении заданного времени от клиента не придет S-ACK, соединение удаляется из очереди, в противном случае соединение переводится в состояние ESTABLISHED. Рассмотрим случай, когда очередь входных соединений уже заполнена, а система получает SYN-пакет, приглашающий к установке соединения. По RFC он будет молча проигнорирован. Затопление SYN-пакетами основано на переполнении очереди сервера, после чего сервер перестает отвечать на запросы пользователей. Самая известная атака такого рода - атака на Panix, нью-йоркского провайдера. Panix не работал в течении 2-х недель. В различных системах работа с очередью реализована по разному. Так, в BSD-системах, каждый порт имеет свою собственную очередь размером в 16 элементов. В системах SunOS, напротив, такого разделения и нет и система просто располагает большой общей очередью. Соответственно, для того, что бы заблокировать, к примеру, WWW-порт на BSD достаточно 16 SYN-пакетов, а для Solaris 2.5 их количество будет гораздо больше. После истечение некоторого времени (зависит от реализации) система удаляет запросы из очереди. Однако ничего не мешает крэкеру послать новую порцию запросов. Таким образом, даже находясь на соединение 2400 bps, крэкер может посылать каждые полторы минуты по 20-30 пакетов на FreeBSD-сервер, поддерживая его в нерабочем состоянии (естественно, эта ошибка была скорректирована в последних версиях FreeBSD). Как обычно, крэкер может воспользоваться случайными обратными IP-адресами при формировании пакетов, что затрудняет его обнаружение и фильтрацию его трафика. Детектирование несложно -- большое количество соединений в состоянии SYN_RECEIVED, игнорирование попыток соединится с данным портом. В качестве защиты можно порекомендовать патчи, которые реализуют автоматическое "прорежение" очереди, например, на основе алгоритма Early Random Drop. Для того, что бы узнать, если к Вашей системе защита от SYN-затопления, обратитесь к поставщику системы. Другой вариант защиты - настроить firewall так, что бы все входящие TCP/IP-соединения устанавливал он сам, и только после этого перебрасывал их внутрь сети на заданную машину. Это позволит Вам ограничить SYN-затопление и не пропустить его внутрь сети
Toggle shoutbox Беседка
|
Страница 1 из 1
Всё о TCP/IP, только тут
Оценка:
Наверх
Цитата#2 Гость_Пофигист_*
Отправлено 11 Октябрь 2007 - 21:20
Архитектура семейства протоколов TCP/IP
• ARP - Отвечает за получение MAC адреса хоста, размещенного в текущей сети, по его IP адресу. Использует broadcast.
• ICMP - Посылка сообщений об ошибках, обнаруженных в процессе передачи пакетов.
• IGMP - Информирует маршрутизаторы о наличии в данной сети multicast группы.
• IP - Обеспечивает маршрутизацию пакетов.
• TCP - Обеспечивает соединение между двумя хостами, с гарантируемой доставкой пакетов.
• UDP - Обеспечивает соединение между двумя хостами, при котором не гарантируется доставка пакетов.
Address Resolution Protocol (ARP)
Для передачи данных по сети хост должен знать MAC адрес хоста, которому передаются данные. Для получения МАС адреса по известному IP адресу служит протокол ARP.
Разрешение локального IP адреса
1. ARP запрос возникает всегда, когда хост пытается связаться с другим хостом. Если IP определит, что IP адрес получателя находится в локадьной сети, то сначала хост проверяет наличие этого адреса в собственном кэше ARP.
2. В случае неудачи ARP строит запрос и посылает его широковещательным сообщением всем хостам подсети. Запрос имеет следующую структуру: “Хост с IP адресом a.b.c.d, сообщите мне Ваш MAC адрес”. Запрос также содержит информацию об IP и MAC адресе отправителя.
3. Каждый хост в подсети получает запрос и проверяет на соответствие свой IP адрес. Если он не совпадает с указанным в запросе, то запрос игнорируется.
4. Если IP адрес, указанный в запросе, совпадает с IP адресом хоста, то хост посылает ARP ответ непосредственно отправителю, используя его MAC адрес. И заносит информацию об IP/MAC адресе отправителя в ARP кэш.
Разрешение удаленного IP адреса
В этом случае инициируется ARP запрос маршрутизатору, который пересылает датаграммы в сеть назначения.
1. Если IP определит, что IP адрес получателя не находится в локадьной сети, то сначала проверяется наличие этого адреса в таблице маршрутизации. В случае неудачи происходит попытка найти MAC адрес default gateway в ARP кэше.
2. Если MAC адрем default gateway не найден, то формируется ARP запрос на определение его MAC адреса. После получения ответа хост посылает информацию через default gateway в сеть назначения.
3. Когда запрос приходит в сеть назначения, то маршрутизатор определяет MAC адрес получателя (см. разрешение локального IP адреса) и посылает ICMP ответ маршрутизатору хоста отправителя.
ARP кэш содержит:
- Динамические адреса – добавляются и удаляются автоматически. Имеют время жизни 10 минут. Если к адресу неи обращений в течении 2 минут, то он удаляется. В противном случае он удаляется через 10 минут. Если при добавлении нового адреса кэш переполнился, то удаляется самый старый адрес для освобождения места для нового.
- Статические адреса – остаются в кэше до перезагрузки компьютера
- Адрес широковещательной рассылки (Hardware broadcast address) FFFFFFFFFFFF – позволяет хосту принимать ARP запросы. Не появляется при просмотре ARP кэша.
Утилита ARP.EXE позволяет просматривать, добавлять и удалять адреса из ARP кэша.
Ключи:
-a, -g Просмотр кэша
-s Добавление статического адреса
-d Удаление адреса
Internet Control Message Protocol (ICMP)
Служит для общения маршрутизатора с хостом, отправляющим или посылающим данные контрольными сообщениями и сообщениями об ошибках. Использует для передачи IP и является его составной частью. Если TCP/IP хост посылает датаграммы другому хосту так часто, что маршрутизаторы не успевают их пересылать, то маршрутизаторы могут посылать сообщения, указывающие хосту замедлить темп передачи датаграмм. Но, если Windows NT компьютер используется как маршрутизатор и не можит отправлять датаграммы с такой частотой, с которой они приходят, то он отбрасывает часть датаграмм не посылая ICMP Source Quench сообщения.
Internet Group Management Protocol (IGMP)
Информирует маршрутизаторы о наличии в данной сети multicast группы. Информация рассылается по маршрутизаторам, поддерживающим рассылку таких сообщений.
Internet Protocol (IP)
- IP не устанавливает непосредственное соединение между хостами, а используют адреса, помещенные в заголовок IP пакета, для передачи их получателям. Выбор пути передачи называется маршрутизацией.
- IP используют поля в заголовке для фрагментации и восстановления датаграмм Internet, когда это необходимо для их передачи через сети с малым размером пакетов.
-
- Не требует подтверждения получения данных. Это означает, что отправитель и получатель не информируются о пропаже пакета или неправильной последовательности получения пакетов.
- Если IP определит, что адрес получателя – локальный, то пакет отправляется непосредственно на хост назначения. В противном случае проверяется таблица маршрутизации на наличие маршрута к хосту назначения. Если маршрут найден, то пакет пересылается по найденному маршруту. В противном случае пакет пересылается на default gateway. После получения маршрутизатором пакета, он передается на обработку IP. IP делает следующее:
1. Уменьшение значение TTL. Если TTL=0, то пакет уничтожается.
2. Фрагментация пакета на более мелкие, если пакет слишком большой для передачи по сети.
3. Если пакет фрагментируется, то IP создает новые заголовки для каждого нового пакета, которые включают в себя:
- Флаг означающий, что применялась фрагментация
- Флаг показывающий, что это не последний фрагмент пакета.
- Смещение фрагмента внутри пакета
4. Пересчитывается контрольная сумма
5. Определяется MAC адреса следующего маршрутизатора
6. Осуществляется пересылка пакета
После прибытия пакета получателю IP собирает все фрагменты в единое целое.
Порты
- Сетевые приложения идентифицируют себя, использую номер порта протокола. Порт может использовать номера от 0 до 65536.
- Для клиентских приложений он назначается операционной системой динамически по запросу сервиса.
- Для наиболее известных серверных приложений номера портов продопределены (этим занимается Internet Assigned Numbers Authority (IANA)) и не меняются. Например: FTP–21 порт, telnet-23 порт.
- В NT 4.0 номера предопределенных портов находятся в файле systemroot%\system32\drivers\etc\services.
Сокеты
Аналог file handle. Конечная точка сетевого соединения. (Переводится как розетка). Для создание приложением сокета необходимо указание следующих параметров:
1. IP адрес хоста
2. Тип сервиса (TCP или UDP)
3. Номер используемого порта
Приложение использует сокеты для соединения с сокетами других приложений и передачи данных между ними.
Transmission Control Protocol (TCP)
Транспортный протокол с гарантированной доставкой пакетов. Данные представляются как поток байтов и могут передаваться в обоих направлениях. Некоторое количество октетов могут упаковываться в сегменты для передачи через системы Internet. Достоверность передачи информации достигается присваиванием каждому сегменту уникального номера в последовательности.
Для проверки доставки сегмента используются подтверждения (ACK), которые возвращаются для каждого посланного сегмента. Если подтверждение не получено, то данные посылаюся еще раз через некоторый интервал времени (timeout). Если сегмент пришел поврежденным, то хост уничтожает этот пакет и не посылает подтверждение получения.
TCP соединение инициализируется путем трех обменов данными (Three-way handshake)
Назначение:
- Синхронизация отправки и получения сегментов.
- Информирование хоста о размере данных, которое он может получить за один раз (windows and segment size).
- Установка виртуального соединения.
-
Порядок установки соединений:
- 1. Инициализация запроса на соединения путем посылки сегмента с установленным флагом синхронизации (SYN).
2. Подтверждение установки соединения хостом получателем путем посылки сегмента, содержащего: Включенный флаг синхронизации (SYN); Число, определяющее стартовый номер последовательности сегментов, которую хост будет отправлять; Подтверждение, содержащее номер стартового сегмента получаемых данных
3. Хост, инициирующий соединения, посылает подтверждение приема данных.
Аналогичная процедура происходит при закрытии соединения.
User Datagram Protocol (UDP)
Обеспечивает соединение с негарантированной доставкой пакетов. Используется в приложениях, не требующих подтверждения получения пакетов (NetBIOS name service, NetBIOS datagram service, SNMP)
#3 Гость_Пофигист_*
Отправлено 12 Октябрь 2007 - 12:56
Протокол IPV6: будущее IP-технологий
Динамичное развитие Интернет-инфраструктуры, различных приложений и услуг на основе Интернет-доступа фактически положило начало переходу к сетям следующего поколения. В условиях ожесточения конкуренции операторы вынуждены не только снижать цены на услуги передачи данных и телематических служб, но и расширять спектр этих услуг, а также уделять больше внимания внедрению новейших IP-технологий, позволяющих снижать затраты и повышать качество сервиса, расширять спектр телематических служб. В последнее время многие операторы стали шире использовать IP-каналы для передачи голосового трафика, снижая, таким образом, свои сетевые расходы. Эксперты агентства TeleGeography, основываясь на анализе данных операторов магистральных сетей, заявили, что в 2003 году объем мирового интернет-трафика вырос на 67%, при этом выпасла доля голосового трафика в сетях IP, составляющего порядка 10% всех международных телефонных переговоров.
Одним из перспективных приложений IP-технологий является развитие телекоммуникационных услуг на основе технологий передачи данных в сетях мобильной связи - мобильный интернет. Наиболее распространенным в мире стандартом мобильной связи является GSM, на долю которого, по данным Ассоциации операторов GSM, приходится 72% рынка цифровой мобильной связи. Этим стандартом связи пользуется более 1 млрд. человек, что составляет примерно пятую часть населения земного шара. Катализатором развития услуг мобильного интернета называют технологию GPRS. Более 200 операторов в мире уже запустили в эксплуатацию системы GPRS, заложив основы технологической базы для новых услуг. Специалисты считают GPRS технологией 2,5G на переходном этапе от второго поколения сетей к третьему – сетям 3G , обладающим более высокой пропускной способностью.
Сети нового поколения мобильной связи к настоящему времени развернуты в США, Европе и Юго-Восточной Азии. Россия также ведет подготовительные работы в этом направлении. Опытные зоны сетей 3G в настоящее время развернуты в европейской части России тремя российским операторами – компаниями МТС, «ВымпелКом» и «МегаФон».
Россия поставила задачу интеграции в единое мировое информационное пространство в качестве равноправного партнера, поэтому поддерживает развитие телекоммуникационных сетей на основе внедрения новых IP-технологий и стандартов. В настоящее время одним из наиболее перспективных считается переход к сетевым транспортным технологиям нового поколения, в первую очередь, путем внедрения в сетях передачи данных нового стека протоколов IPv6. Модернизация сетей на основе этого протокола позволяет решить две основные проблемы, возникающие в результате бурного роста Интернета – необходимо изменить нынешнюю структуру адресных полей, ограничивающую возможности роста количества пользователей Интернета, а также обеспечить безопасность и защищенность передачи данных в реальном времени. Это особенно важно для транспортных сетей. Здесь вполне уместно вспомнить нападение хакеров осенью 2002-го на узлы передачи межконтинентального трафика Интернета.
Таким образом предпосылками модификации базовых протоколов стека IP в России как и во всем мире является:
возрастающая необходимость доступа к разнородным информационным ресурсам. Как следствие этого: повышение производительности компьютеров и коммутационного оборудования; появление большого количества приложений нового типа, работающих с мультимедийной информацией, чувствительных к задержкам передачи пакетов; необходимость резервирования полосы пропускания для определенных приложений.
проникновение Интернета в различные отрасли общественной и хозяйственной деятельности, в том числе увеличение роли Интернет в повседневной жизни населения. Как следствие этого: бурное расширение сети Интернет, быстрое появление новых узлов, а значит дефицит адресного пространства; необходимость удаленного управления элементами (группой элементов) взаимодействующих с Интернет, т. е. необходимость появления новых методов администрирования.
Версия IPv6 призвана развивать и расширять сеть Интернет с целью обеспечения открытости информации, как для ее поставщиков так и пользователей. При этом возможность решения общих первоочередных потребностей (защита и неограниченность адресного пространства, резервирование полосы пропускания) осуществлять не на уровне разрозненных приложений, а на уровне единого протокола передачи данных.
Важно отметить, что внедрение прокола IPv6 позволяет не только существенно снизить эксплуатационные расходы, но и расширить спектр предоставляемых населению услуг передачи данных и телематических служб. Не менее важен и тот факт, что протокол IPv6 обеспечивает наиболее упрощенный переход к сетям нового поколения как в фиксированной, так и в мобильной связи, позволяя создавать специальные механизмы поддержки мобильных сетевых устройств (Mobile IPv6).
Несмотря на то, что Россия не испытывает, в отличие от Китая, Японии и некоторых других стран, дефицита адресного пространства IPv4, работы по внедрению IРv6 начались еще в 1997, когда ряд российских организаций (Институт ядерных исследований РАН (Москва), Институт системного программирования РАН (Москва), Ярославский государственный университет (Ярославль), Уральская государственная академия железнодорожного транспорта (Екатеринбург), Научно-технический центр "Атлас" (Рязань) ) подключились к сети 6 BONE и стали принимать участие в экспериментах по отладке различных функций протокола IPv 6. Наряду с этой сетью также развивается проект научно-образовательной сети 6ren (Research Education Network), направленный на обеспечение сетевого обмена данными с коммерческим качеством по протоколу IPv6.
В настоящее время основные работы по внедрению протокола IPv 6 в России осуществляются не сетевыми операторами, а научно-образовательными сетями RUNNet, RBNet и FreeNet. В университетах в рамках учебного процесса, студенты изучают возможности протокола IPv 6, а также выполняют научную работу, связанную с развитием этого протокола. Кроме того, создан IPv 6 сегмент Москва – Санкт-Петербург, который позволит связать ресурсы суперкомпьютерных центров в Санкт-Петербургском университете, ФТИ им. А.Ф. Иоффе, Межведомственном Суперкомпьютерном центре.
Для интеграции российских IPv6-сетей в глобальную IPv6-инфраструктуру в 2000 году в Москве была создана система IPv6 eXchange , позволяющая обмениваться IPv6-трафиком любым телекоммуникационным операторам. Впервые связь с зарубежными сетями была реализована в апреле 2001 года. В настоящее время пиринговые соглашения заключены с сетями GEANT, Abilene и ASNET (через Starlight - Чикаго), а также соглашение о сотрудничестве с NORDUNet, что обеспечивает взаимодействие Российских и международных научно-образовательных сетей с использованием протокола IPv6. При переходе к новой версии протокола IP на магистральных участках научно-образовательных сетей реализована архитектура с двойным стеком IPv4/IPv6 для обеспечения обратной совместимости с доминирующим сейчас в Интернете протоколом IPv4. Это позволяет расширять абонентскую базу.
Перспективы использования нового IP-протокола уже оценили ряд зарубежных стран, внедривших новую технологию в коммерческих целях. В частности, в Европе первой это сделала еще в 2001 году шведская Telia, оставив в своей сети параллельное сосуществование 4-й и 6-й версии Интернет-протокола на пять лет. В Голландии подобное решение смешанного типа, обеспечивающее доступ как по традиционному протоколу IPv4, так и по новому IPv6, было развернуто при финансовой поддержке правительства в феврале 2002 года. Коммерческая эксплуатация сетей, использующих новый протокол IPv6, началась и в Японии операторами NTT, Nifty и eAccess. В свою очередь компания France Telecom начала работу по оценке стратегии перехода на IPv6 и проводит тестирование прохождения сигналов в сети протокола IPv6, а также взаимодействия между оборудованием при обмене информации в сетях протоколов IPv4 и начавших коммерческую эксплуатацию новых.
Именно коммерческое использование в телекоммуникационных сетях нового IP-протокола является первоочередной задачей для России. Однако, несмотря на высокую эффективность использования современных технологий, их внедрение требует серьезных финансовых затрат.