Во всех предыдущих разделах сам механизм управления маршрутами, порождения пакетов посети старательно обходился стороной, т.к. это предмет особого разговора. Программы управления маршрутами довольно сложны, а функции, которые они выполняют, являются критичными для всей системы в целом.
Основывается система маршрутизации на таблице маршрутов, которая определяет куда пакет с данным IP-адресом следует направлять. Ниже приведен пример такой таблицы, полученный при помощи команды netstat.
Пример 2.1. Таблица маршрутов
quest:/usr/src/sys/i386/conf:\[16\]>netstat -rn Routing tables Destination Gateway Flags Refs Use IfaceMTU Rtt Netmasks: (root node) (0) 0000 ff00 (0) 0000 ffff e000 (root node) Route Tree for Protocol Family inet: (root node) => default 144.206.136.12 UG 1 1081 ed1 - - 127 127.0.0.1 UR 0 0 lo0 - - 127.0.0.1 127.0.0.1 UH 0 51 lo0 - - 144.206 144.206.131.5 UG 0 0 ed1 - - 144.206.64 144.206.136.230 UG 0 0 ed1 - - 144.206.96 144.206.130.135 UG 0 0 ed1 - - 144.206.128 144.206.130.138 U 2 9900 ed1 - - 144.206.192 144.206.192.1 U 2 26203 ed0 - - 194.226.56 144.206.130.207 UGD 0 0 ed1 - - (root node) quest:/usr/src/sys/i386/conf:\[17\]>
В данном примере в левой колонке указаны адреса возможных IP-адресов, которые система принимает из сети, далее идет адрес шлюза для данных адресов, затем флаги маршрутизации, степень использования данного маршрута и интерфейс, на котором данный маршрут обслуживается.
Однако, наша таблица не дает ответа на степень изменчивости данной таблицы. Для этого нам придется снова вернуться к изучению протоколов, но только теперь уже протоколов маршрутизации.
2.9.1. Статическая маршрутизация
В принципе, возможна работа без применения вообще каких-либо протоколов маршрутизации. В этом случае маршрутизацию называют статической. Таблица маршрутов в этом случае строится при помощи команд ifconfig, которые вписывают строки, отвечающие за рассылку сообщений в локальной сети, и команды route, которая используется для внесения изменений вручную.
Вообще говоря, из всей статической маршрутизации выделяют, так называемую, минимальную маршрутизацию. Такая маршрутизация возникает тогда, когда локальная сеть не имеет выхода в Internet и не состоит из подсетей. В этом случае достаточно выполнить команды ifconfig для интерфейса lo и интерфейса Ethernet и все будет работать:
/usr/paul>ifconfig lo inet 127.0.0.1 /usr/paul>ifconfig ed1 inet 144.226.43.1 netmask 255.255.255.0
В таблице маршрутов появятся только эти две строки, но так как сеть ограничена, и пакеты не надо отправлять в другие сети, то модуль ARP будет прекрасно справляться с доставкой пакетов по сети.
Если же сеть подключена к Internet, то в таблицу маршрутов надо ввести, по крайней мере, еще одну строку - адрес шлюза. Делается это при помощи команды route.
Команда route имеет следующий вид:
route <команда> <сеть или хост> <шлюз> <метрика>
В поле "команда" указывается команда работы с таблицей маршрутов:
В поле "сеть или хост" указывается адрес отправки пакета.
В поле "шлюз" указывается IP-адрес, через который следует отправлять пакеты, предназначенные хосту или сети из предыдущего поля.
Поле "метрика" определяет расстояние в числе шлюзов, которые данный пакет пройдет, если его направить по данному маршруту.
Типичным примером применения команды route является назначение шлюза по умолчанию:
/usr/paul>route add default 144.206.160.32
В данном примере все пакеты, адресаты которых не были найдены в локальной сети, отправляются на сетевой интерфейс с адресом 144.206.160.32. Метрика при этом принимается по умолчанию равная 1. Таким образом указывается, что это адрес шлюза.
Для того, чтобы получить таблицу маршрутов, приведенную в примере 2.1, нужно выполнить следующие команды:
/usr/paul>route add 144.206.0.0 144.206.136.5 netmask 255.255.224.0 /usr/paul>route add 144.206.96.0 144.206.130.135 netmask 255.255.224.0 /usr/paul>route add 144.206.128 144.206.130.138 netmask 255.255.224.0 /usr/paul>route add 144.206.192.0 144.206.192.1 netmask 255.255.224.0
Если сравнить эти записи с примером 2.1, то можно заметить, что одной строчки в списке команд не хватает. Это строка, которая описывает маршрут к сети 194.226.56 через шлюз 144.206.130.207. Дело в том, что поле флагов отчета netstat говорит нам, что такого маршрута в первоначальной таблице не было.
В поле флагов отчета netstat мы можем встретить следующие флаги:
U - говорит о том, что маршрут активен и может использоваться для маршрутизации пакетов;
H - говорит о том, что этот маршрут используется для посылки пакетов определенному в маршруте хосту;
G - говорит о том, что пакеты направляются на шлюз, который ведет к адресату;
D - этот флаг определяет тот факт, что данный маршрут был добавлен в таблицу по той причине, что с одного из шлюзов пришел ICMP-пакет, указывающий адрес правильного шлюза, который в нашей таблице отсутствовал.
Строчка, которая описывает не указанный в командах маршрут в таблице маршрутов выглядит следующим образом:
Destination Gateway Flags Refs Use IfaceMTU Rtt 194.226.56 144.206.130.207 UGD 0 0 ed1 - -
Поле флагов содержит флаги: U-маршрут активен, G-пакеты направляются на шлюз и D-маршрут получен по сообщению ICMP о перенаправлении пакетов. Следовательно, первоначально такого маршрута в таблице маршрутов не было.
Если пользователи системы часто ходят в сеть 194.226.56.0, то в таблицу такой маршрут следует добавить:
/usr/paul>route add 194.226.56.0 144.206.130.207 netmask 255.255.224.0
При помощи команды route можно не только добавлять маршруты в таблицу маршрутов, но и удалять их от туда. Делается это по команде delete. Например, если нам надо изменить значение шлюза по умолчанию, то мы можем выполнить следующую последовательность команд:
/usr/paul>route delete default /usr/paul/route add default 144.206.136.10 netmask 255.255.224.0
В данном случае сначала мы удалим из таблицы (пример 2.1) маршрут умолчания, а затем добавим туда новый. При удалении маршрута достаточно назвать только адрес назначения, чтобы route идентифицировала маршрут, который следует удалить.
Можно по команде route получить информацию и о конкретном маршруте, но удобнее все-таки пользоваться командой netstat. В последней и информации указывается больше, и можно получить такую информацию, о которой вы просто можете даже не подозревать, если приходят ICMP-сообщения или используется динамическая маршрутизация.
В заключении обсуждения вопросов статической маршрутизации хотелось бы сделать небольшое замечание по поводу Windows NT. До версии 4.0 в Windows NT штатно существовала только статическая маршрутизация. Для сетей локальных с надежными линиями связи этого вполне достаточно. Фактически, администратору нужно только указать IP-адреса на каждом из сетевых интерфесов, указать адрес шлюза по умолчанию и поднять флажок пересылки пакетов с одного интерфейса на другой. После этого все должно работать. Если локальная сеть подключается к провайдеру, то, как правило, все сводится к получению адреса из сети провайдера для внешнего интерфейса, т.е. интерфейса, который будет связывать вас с адресом шлюза провайдера и адресом своей сети или подсети. Если только провайдер не затеет изменения структуры своей сети, вес будет работать годами без каких-либо изменений. Для таких сетей шлюз на основе Windows NT можно организовать. Однако, не все так просто, когда речь идет о сети или подсети, которые подключаются в качестве части сети, которая не организована по иерархическому принципу. В этом случае возможно изменение наилучших маршрутов гораздо чаще, чем один раз в десятилетие и в этом случае статическая маршрутизация может оказаться недостаточной. Кроме того, важным фактором повышения надежности сетевого взаимодействия является наличие нескольких маршрутов к одним и тем же информационным ресурсам. В случае отказа одного из них можно использовать другие. Но проблема заключается в том, что система всегда использует тот маршрут, который первым встретился в таблице маршрутов, хотя и существуют мультимаршрутные системы, но они распространены, мягко говоря не очень широко. Следовательно, маршруты из таблицы надо удалять и вносить. Если сеть работает не устойчиво, то это превращается в головную боль администратора. Вот почему до версии Windows NT 4.0 рассматривать эту систему в качестве реального претендента на маршрутизатор не представляется возможным. В Windows NT 4.0 появилась поддержка динамической маршрутизации в лице протокола RIP, но поддержки других протоколов маршрутизации пока еще нет.
Таким образом, мы подошли к проблеме автоматического управления таблицей маршрутов на основе информации, получаемой из сети. Такая процедура называется динамической маршрутизацией.
2.9.2. Динамическая маршрутизация
Прежде чем вникать в подробности и особенности динамической маршрутизации обратим внимание на двухуровневую модель, в рамках которой рассматривается все множество машин Internet. В рамках этой модели весь Internet рассматривают как множество автономных систем (autonomous system - AS). Автономная система - это множество компьютеров, которые образуют довольно плотное сообщество, где существует множество маршрутов между двумя компьютерами, принадлежащими этому сообществу. В рамках этого сообщества можно говорить об оптимизации маршрутов с целью достижения максимальной скорости передачи информации. В противоположность этому плотному конгломерату, автономные системы связаны между собой не так тесно как компьютеры внутри автономной системы. При этом и выбор маршрута из одной автономной системы может основываться не на скорости обмена информацией, а надежности, безотказности и т.п.
Рис. 2.24. Схема взаимодействия автономных систем
Сама идеология автономных систем возникла в тот период, когда ARPANET представляла иерархическую систему. В то время было ядро системы, к которому подключались внешние автономные системы. Информация из одной автономной системы в другую могла попасть только через маршрутизаторы ядра. Такая структура до сих пор сохраняется в MILNET.
На рисунке 2.24 автономные системы связаны только одной линией связи, что больше соответствует тому, как российский сектор подключен к Internet. В классических публикациях по Internet взаимодействие автономных частей чаще обозначают пересекающимися кругами, подчеркивая тот факт, что маршрутов из одной автономной системы в другую может быть несколько.
Обсуждение этой модели Internet необходимо только для того, чтобы объяснить наличие двух типов протоколов динамической маршрутизации: внешних и внутренних.
Внешние протоколы служат для обмена информацией о маршрутах между автономными системами.
Внутренние протоколы служат для обмена информацией о маршрутах внутри автономной системы.
В реальной практике построения локальных сетей, корпоративных сетей и их подключения к провайдерам нужно знать, главным образом, только внутренние протоколы динамической маршрутизации. Внешние протоколы динамической маршрутизации необходимы только тогда, когда следует построить закрытую большую систему, которая с внешним миром будет соединена только небольшим числом защищенных каналов данных.
К внешним протоколам относятся Exterior Gateway Protocol (EGP) и EGP предназначен для анонсирования сетей, которые доступны для автономных систем за пределами данной автономной системы. По данному протоколу шлюз одной AS передает шлюзу другой AS информацию о сетях из которых состоит его AS. EGP не используется для оптимизации маршрутов. Считается, что этим должны заниматься протоколы внутренней маршрутизации.
BGP - это другой протокол внешней маршрутизации, который появился позже EGP. В своих сообщениях он уже позволяет указать различные веса для маршрутов, и, таким образом, способствовать выбору наилучшего маршрута. Однако, назначение этих весов не определяется какими-то независимыми факторами типа времени доступа к ресурсу или числом шлюзов на пути к ресурсу. Предпочтения устанавливаются администратором и потому иногда такую маршрутизацию называют политической маршрутизацией, подразумевая, что она отражает техническую политику администрации данной автономной системы при доступе из других автономных систем к ее информационным ресурсам. Протокол BGP используют практически все российские крупные IP-провайдеры, например крупные узлы сети Relcom.
К внутренним протоколам относятся протоколы Routing Information Protocol (RIP), HELLO, Intermediate System to Intermediate System (ISIS), Shortest Path First (SPF) и Open Shortest Path First (OSPF).
Протокол RIP (Routing Information Protocol) предназначен для автоматического обновления таблицы маршрутов. При этом используется информация о состоянии сети, которая рассылается маршрутизаторами (routers). В соответствии с протоколом RIP любая машина может быть маршрутизатором. При этом, все маршрутизаторы делятся на активные и пассивные. Активные маршрутизаторы сообщают о маршрутах, которые они поддерживают в сети. Пассивные маршрутизаторы читают эти широковещательные сообщения и исправляют свои таблицы маршрутов, но сами при этом информации в сеть не предоставляют. Обычно в качестве активных маршрутизаторов выступают шлюзы, а в качестве пассивных - обычные машины (hosts).
В основу алгоритма маршрутизации по протоколу RIP положена простая идея: чем больше шлюзов надо пройти пакету, тем больше времени требуется для прохождения маршрута. При обмене сообщениями маршрутизаторы сообщают в сеть IP-номер сети и число "прыжков" (hops), которое надо совершить, пользуясь данным маршрутом. Надо сразу заметить, что такой алгоритм справедлив только для сетей, которые имеют одинаковую скорость передачи по любому сегменту сети. Часто в реальной жизни оказывается, что гораздо выгоднее воспользоваться оптоволокном с 3-мя шлюзами, чем одним медленным коммутируемым телефонным каналом.
Другая идея, которая призвана решить проблемы RIP, - это учет не числа hop'ов, а учет времени отклика. На этом принципе построен, например, протокол OSPF. Кроме этого OSPF реализует еще и идею лавинной маршрутизации. В RIP каждый маршрутизатор обменивается информацией только с соседями. В результате, информации о потере маршрута в сети, отстоящей на несколько hop'ов от локальной сети, будет получена с опозданием. Лавинная маршрутизация позволяет решить эту проблему за счет оповещения всех известных шлюзов об изменениях локального участка сети.
К сожалению, многовариантную маршрутизацию поддерживает не очень много систем. Различные клоны Unix и NT, главным образом ориентированы на протокол RIP. Достаточно посмотреть на программное обеспечение динамической маршрутизации, чтобы убедится в этом. Программа routed поддерживает только RIP, программа gated поддерживает RIP, HELLO, OSPF, EGP и BGP, в Windows NT поддерживается только RIP.
Поэтому мы рассмотрим возможность динамического управления таблицей маршрутов только по протоколу RIP.
2.9.3. Программа routed
Программа routed поставляется с любым клоном Unix и используется в качестве демона протокола RIP по умолчанию. Как правило, она используется без аргументов и запускается в момент загрузки операционной системы. Однако, если машина не является шлюзом, то имеет смысл указать флаг "-q". Этот флаг означает, что routed не будет посылать информации в сеть, а только будет слушать информацию от других машин. Обычно, активными являются шлюзы, а все остальные системы являются пассивными.
Однако, часто бывает полезно при начальной загрузке инициализировать таблицу маршрутов и определить строки, которые из нее не следует удалять ни при каких условиях. Самый типичный случай - назначение шлюза по умолчанию. Для этой цели можно использовать файл /etc/gateways, который программа routed просматривает при запуске и использует для первоначальной настройки таблицы маршрутов. Содержание этого файла может выглядеть следующим образом:
В данном примере адрес 0.0.0.0 используется для определения адреса умолчания, машина 144.206.136.10 - это шлюз по умолчанию, метрика определяет число hop'ов до этого шлюза, а параметр "passive" - говорит о том, что даже если с этого шлюза никакой информации о маршрутах не приходит, то его все равно не надо удалять из таблицы маршрутов. Последний параметр указывается в том случае, если шлюз только один, если же возможно использование другого шлюза и эти шлюзы активно извещают машины сети о своих таблицах маршрутов, то следует вместо passive использовать active:
В этом случае пассивный шлюз из таблицы маршрутов будет удален, а тот, который может исполнять функции реального шлюза будет в таблицу включен. В сети kiae изменение шлюза по умолчанию можно наблюдать по несколько раз в день.
Когда используется только Ethernet, то программа routed может использоваться и на машинах шлюзах, но если система связана с внешним миром через SLIP или PPP, то использование routed может привести к потере самого главного маршрута. Он будет удален из таблицы из соображений неактивности. В этом случае лучше всего использовать программу gated.
2.9.4. Программа gated
Gated - это коллективный продукт американских университетов, который был разработан для работы сети NFSNET. Права copyright закреплены за Корнельским университетом, хотя части кода являются собственностью других университетов и ассоциаций.
Gated - это модульная программа предназначенная организации много функционального шлюза, который мог бы обслуживать как внутреннюю маршрутизацию, так и внешнюю. Gated поддерживает протоколы RIP (версии 1 и 2), HELLO, OSPF версии 2, EGP версии 2 и BGP версий от 2 до 4. Все перечисленные возможности относятся к версии 3.5. На системах типа HPUX 9.x или IRIX 6.x могут стоять и более ранние версии, которые всего этого набора протоколов могут и не поддерживать.
Рассмотрим два основных примера использования gated в локальной сети: вместо routed на обычной машине и на машине-шлюзе в другую сеть. При этом будем опираться на следующую схему, изображенную на рисунке 2.25.
Рис. 2.25. Подключение локальной сети к Internet и настройки gated
Gated настраивается при помощи своего файла конфигурации /etc/gated.conf. Именно в нем пишутся все команды настройки, которые gated проверяет при запуске.
При работе на обычной машине, системе надо только указать интерфейс и протокол динамической маршрутизации, который gated должна использовать:
В большинстве случаев достаточно просто указать протокол, т.к. интерфейс попадет в таблицу маршрутизации после выполнения команды ifconfig.
Теперь обратимся к настройкам gated на машине-шлюзе. В принципе, можно также обойтись одним указанием на протокол RIP и все будет работать. Если же надо сохранять маршруты через интерфейсы в таблице маршрутов, то следует указать в файле конфигурации оба интерфеса:
Однако можно использовать и более сложное описание, основанное на логике работы gated. А логика эта состоит в том , что gated объявляет соседним шлюзам по RIP, что подсеть 144.206.160.0 доступна через интерфейс 144.206.130.137, в свою очередь для подсети gated объявляет, что весь мир доступен через интерфейс 144.206.160.32. Очевидно, что это логика заимствована из архитектуры внешних протоколов маршрутизации и распространена на протоколы внутренние. Это позволяет вести описание маршрутов в едином ключе.
Первая команда export анонсирует подсеть 144.206.160.0 через интерфейс 144.206.130.137. При этом сообщается, что это шлюз в данную подсеть, т.е. интерфейс 144.206.130.137 расположен на машине, которая включена в эту подсеть. О том, что пакеты для подсети надо посылать непосредственно на этот интерфейс говорит предложение proto direct, а то, что интерфейс стоит на шлюзе в подсеть говорит метрика, равная 0.
Второе предложение сообщает всем машинам подсети через интерфейс 144.206.160.32 все маршруты, которые данный шлюз получает из подсети 144.206.128.0 через интерфейс 144.206.130.137. Фактически осуществляется сквозная пересылка всей информации во внутрь системы.
При написании управляющих предложений export следует всегда помнить, что внешнее предложение определяет всегда интерфейс, через который сообщается информация, а внутреннее предложение определяет источник, через который эту информацию получает gated.
Важным является и синтаксис предложений, который сильно смахивает на синтаксис языка программирования С.
Во всех руководствах по gated приводится еще один пример, когда сеть, через подсеть подключают к Internet. Здесь приведем пример из руководства к gated 3.5.
В данном случае все, что gated получает из локальной сети через интерфейс 136.66.1.5 транслируется в подсеть, которая связывает данную сеть с Internet, через интерфейс 136.66.12.3 (речь идет только о маршрутах, так как gated работает только с таблицей маршрутов).
Второе предложение export определяет куда следует отправлять информацию по умолчание из сети, чтобы она достигла адресата, расположенного за пределами данной локальной сети. Адрес 0.0.0.0, который соответствует любой машине за интерфейсом 136.66.12.3 анонсируется через интерфейс 136.66.1.5. для всей локальной сети.
И последние замечания о gated. Они касаются возможности управлять доступом к машинам локальной сети. Если маршрут доступа к машине или локальной подсети не экспортировать во внешний мир, то о машине или подсети никто и не узнает. Правда в этом случае нельзя использовать эти машины для доступа к внешним ресурсам также.
В одном из докладов Министерства Обороны США, выполненном по запросу Конгресса, отмечалось, что в последнее время число атак на компьютеры вооруженных сил увеличилось. При этом атакующие, главным образом, используют программы захвата и анализа трафика TCP/IP, который передается по сети Internet. Надо сказать, что проблема эта не новая. Еще во время начала проекта Athena в Масачусетском Технологическом Институте, в результате которой появилась система Керберос, одной из основных целей проекта называлась защита от захвата и анализа пакетов.
До последнего времени, в российском секторе Internet хотя и знали, что такая проблема существует, хотя провайдеры и пользовались сами сканированием, серьезных шагов по защите от этого сканирования не предпринимали. В данном случае речь идет о том, что требование тотальной защиты, как это имеет место во всех зарубежных коммерческих и правительственных сетях, не выдвигалось. Не смотря на то, что Relcom первым продемонстрировал в 1991 году возможности бесконтрольного, со стороны государства, распространения информации через Internet, ни Demos, ни AO Relcom не ставили перед собой задачи сплошной защиты своих внутренних сетей от атаки из вне при помощи просмотра содержания IP-пакетов.
Надо сказать, что довольно долгое время такая практика себя оправдывала. Серьезных нарушений в работе сети не происходило, а атаки на шлюзы и локальные подсети успешно отбивались системами фильтрации трафика. Но к осени 1996 года ситуация изменилась. И главной причиной изменения стало внедрение системы доступа к сети по dial-ip. Теперь в сети появилось большое количество случайных людей со стороны. Кроме того, внедрение Internet во многих московских вузах привело к увеличению среди пользователей сети доли студентов. При этом следует отметить, что доступ из академических и учебных заведений в Internet по большей части остается бесплатным для пользователей, а это значит, что ресурсами сети можно пользоваться круглосуточно, не заботясь о том, сколько у тебя в кармане денег.
Склонность человеческой натуры к подсматриванию и подглядыванию хорошо известна. А если за это еще и не накажут, и заниматься этим можно сколько душе угодно, то вероятность появления любопытных резко возрастает.
К осени 1996 года число зарегистрированных пользователей Dial-IP составило несколько тысяч человек только в AO Relcom. SovamTeleport начал заниматься предоставлением такого доступа на полгода раньше (с осени 1995), следовательно там число пользователей должно быть еще больше. Кроме того, многие университеты, учебные заведения и научно-исследовательские организации для своих сотрудников создали модемные пулы. Естественно, что администраторы подсетей или их близкие друзья также не могли пройти мимо возможности работать на дому. Исходя из этого, можно предположить, что только в Москве число пользователей Dial-IP составляет несколько десятков тысяч человек.
Совершенно очевидно, что среди такого количества людей обязательно найдется некто, кто посвятит все свое свободное время исследованию сети, тем более что слава всемогущих хакеров, взламывающих компьютеры Пентагона, не дает спать спокойно многим.
И вот в середине сентября 1996 года прозвенел первый звоночек. Точнее, на эту проблему обратил внимание наших провайдеров CERT (Computer Emagency Response Team). В Канаде были зарегистрированы попытки входа в систему по различным портам TCP с указанием действительно существовавших идентификаторов и паролей пользователей. Попытку зарегистрировала программа межсетевого фильтра (FilreWall), о чем и сообщила администратору. Администратор оказался человеком дотошным и стал выяснять кто и откуда пытался проникнуть в систему.
Двухнедельные занятия по изучению файлов отчетов о доступе к основным компьютерам центров управления российскими сетями показали удручающую картину. Действительно, на многих машинах наблюдались посещения в режиме привилегированных пользователей с адресов, которые не ассоциировались ни с одним из тех лиц, кому такой доступ был разрешен. Были найдены и списки идентификаторов и паролей, и инструмент, которым пользовались взломщики, и отчеты этой программы, которые хранились злоумышленниками на компьютерах за пределами российской части Internet.
Собственно определить кто и откуда коллекционировал информацию не представляло большого труда, но главным был вопрос о том, что в этом случае следует предпринимать. Ведь подобного прециндента в практике российского Internet-сообщества еще не было.
Во-первых, конечно надо было защищаться. Средства защиты хорошо известны - это фильтрация трафика и шифрация обменов. Благо на настоящий момент Гос.тех комиссией выдано более сотни лицензий на возможность проведения такого сорта мероприятий и сертифицировано как аппаратное, так и программное обеспечение. Но пассивная оборона - это только половина дела, хотелось еще и наказать наглецов. А вот с последним и возникли проблемы. В принципе, по новому российскому законодательству предусмотрены наказания вплоть до лишения свободы на строк до семи лет за компьютерные преступления, но для этого надо вести следственные мероприятия, передавать дело в суд и т.п. Все это не входит в компетенцию провайдеров, потому что может занять много времени, а кроме того о таких прецидентах, что-то пока ничего слышно не было.
Общение с организацией, предоставившей Dial-IP вход, также не дало гарантий от повторения подобных инцидентов. Поэтому было принято решение зафильтровать сетки, с которых осуществлялся первоначальный вход в сеть при взломе.
К чему привела эта практика, на своей шкуре почувствовали многие пользователи сети. На первый взгляд, вроде ничего страшного, ну не пускают тебя к отечественным информационным ресурсам, а мы, что называется, и не хотели. Будем ходить на Запад. Но не тут-то было.
Дело в том, что к отечественным информационным сервисам относится и служба DNS. DNS обслуживает запросы на получение по доменному имени машины ее IP-адреса. Каждый домен имеет несколько серверов, которые могут удовлетворить запрос пользователя, но только один из них является главным. Все остальные время от времени сверяют информацию в своей базе данных с информацией в базе данных главного сервера. При фильтрации обычно закрывают порты TCP. Это значит, что отвечать на запросы, которые используют 53 порт UDP, сервер будет, а вот осуществить копирование описания зоны на дублирующий сервер, которое производится по 53 порту TCP, межсетевой фильтр не даст. Как результат, дублирующие сервера будут отказывать в обслуживании, и доступ к ресурсам, из-за невозможности получить за приемлемое время IP-адрес, будет затруднен.
В результате доступ к такому информационному ресурсу, как World Wide Web, происходит через "пень-колоду". Что говорить о доступе к отечественным ресурсам. Ведь не "видно" не только тех, кто спрятался за "стенами", но и тех, кто разместил там серверы DNS. Особенно пикантной становится ситуация, если в защищенную зону попадет root-сервер DNS для доменов SU и RU.
Сколько теперь будет успокаиваться поднятая этими действиями волна - не известно, но то, что провайдеры, к которым в данном случае относятся и некоммерческие сети, должны вместе договориться об общих принципах политики безопасности - это очевидно, в противном случае ситуация будет повторяться постоянно, но уже гораздо с большими последствиями для всех заинтересованных сторон.
И попутно, хотелось бы заметить, что всякие разговоры о проблемах с сервером InfoArt, когда, как утверждалось, было подменено содержание базы данных службы доменных имен, могут являться следствием указанных выше причин. Хотя то, что события совпали по времени может быть простой случайностью.
После столь долгого вступления хотелось все же обратиться к тому средству, которым воспользовались злоумышленники. Программы, позволяющие захватывать пакеты из сети называются sniffers (буквально - "нюхачи", но мне кажется лучше назвать их "пылесосами", т.к. сосут они все подряд, хотя есть и интеллектуальные, которые из всех пакетов выбирают только то, что нужно).
Первые такие программы использовали то, что в сетях Ethernet все компьютеры подсоединяются на один кабель. В обычном режиме карта Ethernet принимает только те фреймы, которые ей предназначены, т.е. указаны в заголовке фрейма. Однако в целях отладки многие карты можно заставить работать в режиме "пылесоса", тогда они будут принимать все фреймы, которые передаются по кабелю. Такой режим работы карты называется promiscuous mode. Если можно получить пакет в машину, то, следовательно, его можно проанализировать.
Главная проблема, связанная с "нюхачами" заключается в том, чтобы они успевали перерабатывать весь трафик, который проходит через интерфейс. Код одной из достаточно эффективных программ этого типа (Esniff) был опубликован в журнале Phrack. Esniff предназначена для работы в Sunos. Программа очень компактная и захватывает только первые 300 байтов заголовка, что вполне достаточно для получения идентификатора и пароля telnet-сессии. Программа свободно распространяется по сети и каждый желающий может ее "срисовать" по адресу ftp://coombs.anu.edu.au/pub/net/log. Существуют и другие программы этого типа и не только для платформ Sun. Это Gobler, athdump, ethload для MS-DOS или Paketman, Interman, Etherman, Loadman - для целого ряда платформ, которые включают в себя Alpha, Dec-Mips, SGI и др. "Нюхачи" существуют не только для Ethernet. Многие компании выпускают системы анализа трафика и для высокоскоростных линий передачи данных. Достаточно зайти на домашнюю страницу AltaVista и запустить запрос, состоящий из одного слова "sniffer" как вы сразу получите целый список страниц на данную тему. Лучше правда "sniffer AND security", т.к. система может понять вас буквально и выложить информацию и об органах дыхания.
Когда программы анализа трафика писались, то предполагалось, что пользоваться ими будут профессионалы, отвечающие за надежность работы сети. Однако, как это часто бывает, система оказалась обоюдоострой. Как же бороться с непрошенными гостями?
Во-первых, если система многопользовательская, то при помощи команды ifconfig можно увидеть интерфейс, который работает в режиме "пылесоса". Среди флагов появляется значение PROMISC. Однако, злоумышленник может подменить команду ifconfig, чтобы она не показывала этот режим работы. Поэтому следует убедиться в том, что программа та, которая была первоначально, а во-вторых, ее протестировать.
Обнаружить "пылесос" на других машинах сети нельзя, особенно это касается машин с MS-DOS. Поэтому от сканирования защищаются путем установки межсетевых фильтров и введения механизмов шифрации либо всего трафика, либо только идентификаторов и паролей.
Существуют и аппаратные способы защиты. Ряд сетевых адаптеров не поддерживает режим promiscuous mode. Если эти карты использовать для организации локальной сети, то можно обезопасить себя от "подглядывания".
Для того, чтобы "подглядывать" вовсе не обязательно включать режим принятия всех пакетов. Если запустить программу анализа пакетов на шлюзе, то вся информация также будет доступна, т.к. шлюз пропускает через себя все пакеты в/из локальной сети, для которой он является шлюзом.
В заключении хотелось бы сказать, вслед за Jeff Schiller и Joanne Costell из Масачусетского Технологического Института, что, для использования sniffer не надо иметь семи пядей во лбу, не надо иметь диплом о высшем образовании и вообще запустить программу и воспользоваться результатами может и младенец. То, что кто-то смог наколлекционировать чужие пароли и идентификаторы не говорит о его уме или профессиональной пригодности. Единственным последствием таких действий станет неминуемое ужесточение правил использования сети, от которого плохо станет всем.
Назад |
Содержание |
Вперед
[an error occurred while processing this directive]
net 0.0.0.0 gateway 144.206.136.10 netric 1 passive
net 0.0.0.0 gateway 144.206.136.10 netric 1 active
#
# Interface shouldn`t be removed from routing table
#
interface 144.206.160.40 passive ;
#
# routing protocol is rip.
#
rip yes;
# Interfaces shouldn`t be removed from routing table
interface 144.206.160.32 passive ;
interface 144.206.130.137 passive ;
# routing protocol is rip.
rip yes;
rip yes;
export proto rip interface 144.206.130.137
{
proto direct
{
announce 144.206.160.0 metric 0 ;
} ;
} ;
export proto rip interface 144.206.160.32
{
proto rip interface 144.206.130.137
{
announce all ;
} ;
} ;
rip yes;
export proto rip interface 136.66.12.3 metric 3
{
proto rip interface 136.66.1.5
{
announce all ;
} ;
} ;
export proto ripinterface 136.66.1.5
{
proto rip interface 136.66.12.3
{
announce 0.0.0.0 ;
} ;
{ ;
2.10 Анализ и фильтрация TCP/IP пакетов