Основные проблемы администрирования сетей TCP/IP и информационных технологий Internet

Рис. 2.20 - Динамическое назначение портов. Образование сокетов

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

2.6 Основные принципы IP-маршрутизации

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

Прежде чем перейти к описанию самой процедуры, введем пример сети, на которой будем рассматривать маршрутизацию пакетов (рисунок 2.21).

Рис. 2.21 - Пример фрагмента локальной сети

На рисунке 2.21 изображены два фрагмента подсетей (144.206.160.0 и 144.206.128.0) сети класса B (144.206.0.0). Машина с интерфейсами, которые имеют адреса 144.206.160.32 и 144.206.130.137 - это шлюз между двумя подсетями, а машина с адресом сетевого интерфейса 144.206.130.3 - это шлюз сети с другой сетью, которая подключена к Internet.

Рассмотрим сначала путь пакета от машины с адресом 144.206.160.40 к машине с адресом 144.206.160.33. Предположим, что к этой машине пользователь 144.206.160.40 еще не обращался. В рамках такого обмена машине достаточно знать только свой IP-адрес. Прежде чем отправить пакет, модуль ARP проверит, существует ли соответствие между IP-адресом получателя и физическим адресом какого-либо интерфейса включенного в локальную сеть. В нашем случае такого соответствия еще нет, поэтому в сеть будет отправлен широковещательный запрос на получение физического адреса по заданному IP-адресу. В ответ машина 144.206.160.33 сообщит свой адрес, после чего пакет будет отправлен в сеть. В поле физического адреса в фрейме протокола канального уровня будет указан адрес машины 144.206.160.33. Вообще говоря, такая процедура была разработана для Ethernet, но в последнее время ARP стали применять и для других физических сред, в частности, для FrameRelay.

Теперь отправим пакет машине из другой подсети 144.206.130.138. В этом случае на широковещательный запрос мы ответа не получим. Но пакет отправлять как-то надо. Для этой цели в описании маршрутов пакетов всегда есть IP-адрес, на который следует отправлять пакеты по умолчанию, если нет другого способа их рассылки. Естественно, что это адрес шлюза. Для машины 144.206.160.40 таким адресом является адрес 144.206.160.32. Физический адрес этого интерфейса получают точно также, как мы до этого получили физический адрес интерфейса 144.206.160.33. Принципиальное различие здесь заключается в том, что в первом случае адреса получателя и отправителя во фрейме физического протокола совпадали с адресами, которые указаны для IP-адресов из IP-пакета в таблице ARP. В случае шлюза здесь можно обнаружить несоответствие. Во фрейме в качестве получателя будет указан адрес интерфеса 144.206.160.32, в то время как в IP-пакете будет указан IP-адрес 144.206.130.138. Но ведь этому IP-адресу соответствует совсем другой физический адрес. Если быть более точным, то другой адрес будет соответствовать в сети Ethernet, если же речь идет о FrameRelay, то там может применяться относительная система адресации, что может приводить к равенству физических адресов.

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

Если пакет отправляется в Internet, то шлюз не найдет физического адреса машины, и будет вынужден воспользоваться адресом рассылки по умолчанию. Таким образом, пакет попадет на шлюз через 144.206.130.3 и там будет решаться его судьба.

При рассмотрении стека протоколов TCP/IP на компьютере с одним сетевым интерфейсом было не очень понятно, зачем IP дублирует физический адрес, например, Ethernet, ведь каждому адресу Ethernet ставился в соответствие один IP-адрес. При рассмотрении архитектуры стека протоколов шлюза этот вопрос становится более понятным.

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

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

Рис. 2.22 - Архитектура шлюза 144.206.130.137-144.206.160.32

2.7 Настройка операционной системы и сетевые интерфейсы

Прежде чем начать описание настроек сетевых интерфейсов, обратим свое внимание на особенности операционной системы, которая должна работать с сетью TCP/IP. Чаще всего при этом подразумевается операционная система Unix. Мы не будем отступать от этой традиции. Рассмотрим настройку ОС вручную, а не с использованием диалоговых средств, которые широко применяются в HP-UX, IRIX, SCO и т. п. В Unix все равно все сводится к выполнению тех же самых команд, но только программами или скриптами. Администратор всегда может воспользоваться интерфейсом командной строки, чтобы поправить настройки, выполненные ранее рекомендованными в руководстве по администрированию средствами.

Для того, чтобы система работала со стеком протоколов TCP/IP необходимо соответствующим образом настроить ядро системы. В системах клона BSD конфигурация определяется в фале типа /usr/sys/conf, Например, во FreeBSD 2.x, - это файл /sys/i386/conf/GE-NERIC, если речь идет о только что установленной системе.

Обычно, на основе этого файла делают копию, которую называют local, и в этой копии проводят изменения настроек. В этом файле следует определить, чаще всего раскомментировать, строки, которые определяют сетевые интерфейсы, например, ed0 или ed1, если речь идет о Ethernet. Кроме этого, если машина будет работать шлюзом, нужно указать опцию GATEWAY, если нужно использовать распределенную файловую систему, то нужно заказать также соответствующие опции. Для таких протоколов, как SLIP и PPP, нужно определить еще и псевдоустройства. Ниже приведен пример такого файла конфигурации, точнее фрагмент.

Файл конфигурации ядра FreeBSD 2.x.

quest:/usr/src/sys/i386/conf:\[6\]>cat QUEST

options NFS #Network File System

options GATEWAY #Host is a Gateway (forwards packets)

device sio0 at isa? port "IO_COM1" tty irq 4 vector siointr

device sio1 at isa? port "IO_COM2" tty irq 3 vector siointr

device lpt0 at isa? port? tty irq 7 vector lptintr

device ed0 at isa? port 0x280 net irq 9 iomem 0xd8000 vector edintr

device ed1 at isa? port 0x300 net irq 5 iomem 0xd8000 vector edintr

pseudo-device loop

pseudo-device ether

pseudo-device log

pseudo-device sl 2

Из этого фрагмента видно, что данная машина позволяет работать с распределенной файловой системой, является шлюзом, имеет два сетевых интерфейса Ethernet: ed0 и ed1, а также еще два интерфейса на последовательных портах: sl0 и sl1, что соответствует портам sio0 и sio1.

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

В системах клона System 5, настройки ядра распределены по многим фалам. Здесь лучше воспользоваться стандартными средствами конфигурации типа SAM в HP-UX, т.к. можно просто забыть что-нибудь подправить.

При настройках Windows NT систему можно сконфигурировать для работы с сетями TCP/IP как при установке, так и потом, по мере необходимости. Правда отложенная конфигурация приведет к перезагрузке системы. Настраивается сеть из меню network в меню control panel. Там также определяется тип интерфейса и копируется с дистрибутива драйвер для данного интерфейса. Потом для интерфейса определяется семейство протоколов, где среди протоколов Microsoft можно найти и TCP/IP. Далее интерфейсу назначается IP-адрес, определяется шлюз и сервер доменных имен. Другие параметры, типа сервиса WINS (Windows Internet Name System), мы рассматривать не будем, т.к. это касается только Windows, а не Internet вообще.

При установке стека TCP/IP на машины с операционной системой MS-DOS следует иметь в виду, что здесь надо установить все выше описанное, но только в отличии от выше перечисленных операционных систем все программное обеспечение является прикладными задачами, а не частью операционной системы, поэтому никакой перенастройки ядра не происходит. Общая схема машины с OC MS-DOS, поддерживающей стек TCP/IP будет выглядеть так, как показано на рисунке 2.23.



Рис. 2.23 - Структура стека программного обеспечения для поддержки стека протоколов TCP/IP на персональном компьютере

Естественно, что все эти модули, которые представлены на рисунке 2.23 должны быть указаны в файлах config.sys и autoexec.bat. Примеры содержания файлов autoexec.bat и config.sys приведены ниже и основаны они на настройке персонального компьютера notebook, который работает с сетью либо через сетевой PCMCI-адаптер Ethernet, либо через PCMCI-модем, что и отражено в вариантной загрузке.

Пример файла autoexec.bat

@ECHO OFF

set tz=MSK

set temp=c:\temp

set tmp=c:\temp

PATH C:\WINWORD;C:\;C:\NC5;C:\WINDOWS;C:\DOS;C:\UT;C:\ME;c:\spelchek\g4;

c:\spelchek\logs;c:\photo;

goto %config%

:Network

PATH %PATH%c:\network\tel;c:\network\xfs;

:Dial-in

:Local

LH CYRILLIC

LH C:\DOS\SHARE.EXE /l:500 /f:5100

nc

При работе через сетевой адаптер все интерфейсы устанавливаются только в config.sys, а в autoexec.bat подправляется только переменная окружения PATH.

Содержание файла config.sys

[menu]

menuitem=Local, Load Computer without any drivers.

menuitem=Network, Start Computer with Ethernet Network Conection.

menuitem=Dial-in, Start Computer in Local Mode with Dial-in Connection.

[common]

rem common statments

[Local]

rem ordinal

[Network]

rem network interface installation

device=c:\network\pktdrv\accopen.exe /int=5 /port=300 /mem=0000

DEVICE=C:\DOS\HIMEM.SYS

DEVICE=c:\dos\emm386.exe noems

[Dial-in]

DEVICE=C:\DOS\HIMEM.SYS

DEVICE=c:\dos\emm.386.exe noems

; PCMCI modem

DEVICEHIGH=C:\PCMCIA\SSVADEM.SYS

DEVICEHIGH=C:\PCMCIA\AMICS.SYS

DEVICEHIGH=C:\PCMCIA\PCMODEM.SYS

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

Таким образом, после сборки нового ядра в системах Unix и Windows NT, или после выполнения настройки MS-DOS в системе появляются сетевые интерфейсы, стек протоколов TCP/IP и возможность совместной настройки интерфейсов и стека протоколов.

2.8 Настройка сетевых интерфейсов

Настройкой сетевых интерфейсов называют определение параметров обмена данными через сетевой интерфейс и присвоение ему IP-адреса. Сначала разберем, как это делается для интерфесов Ethernet, а потом уже для последовательных портов.

2.8.1 Настройка Ethernet-интерфейса

В данном случае никаких параметров настраивать не надо. Следует только назначить IP-адрес. Делается это по команде ifconfig:

/usr/paul>ifconfig ed0 inet 144.206.130.138 netmask 255.255.224.0

В данном случае интерфесу ed0 назначается адрес 144.206.130.138, при этом на сети установлена маска 255.255.224.0. В общем случае команда ifconfig имеет следующий формат:

ifconfig interface address_family [address [dest_address]] [parameters]

В этой команде параметры означают следующее:

interface - имя сетевого интерфейса;

address_famaly - тип адреса. В нашем случае - это inet, т.е. адрес Internet. Данное значение задается по умолчанию;

address - IP-адрес источника. Обычно в этом поле указывают IP-адрес который назначается сетевому интерфейсу. Если речь идет об интерфейсе Ethernet то этого адреса достаточно для его настройки.

dest_address - IP-адрес получателя. Данный адрес указывается для интерфейсов типа "точка-точка", например, для SLIP (sl0) или PPP (ppp0). В таких соединениях к концам линии связи подключены только два интерфейса и надо задать адрес обоих. В предыдущем поле (address) задают адрес своего интерфейса, а в данном поле интерфейса, установленного на другом конце линии.

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

Команда ifconfig может быть использована и для получения информации об интерфейсе. Для этого в ней надо указать только имя:

quest:/usr/src/sys/i386/conf:\[14\]>ifconfig ed1

ed1: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX>

inet 144.206.130.138 netmask ffffe000 broadcast 144.206.159.255

quest:/usr/src/sys/i386/conf:\[15\]>

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

Однако более исчерпывающую статистику можно получить при помощи команды netstat:

quest:/usr/src/sys/i386/conf:\[19\]>netstat -ain

Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll

ed0 1500 <Link>0.0.1b.12.32.46 52848 0 45380 0 0

ed0 1500 144.206.192 144.206.192.1 52848 0 45380 0 0

ed1 1500 <Link>0.0.1b.12.32.32 659682 2354 45708 276 4423

ed1 1500 144.206.128 144.206.130.138 659682 2354 45708 276 4423

lo0 65535 <Link> 138 0 138 0 0

lo0 65535 127 127.0.0.1 138 0 138 0 0

sl0* 296 <Link> 0 0 0 0 0

sl1* 296 <Link> 0 0 0 0

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

Кроме этого, следует обратить внимание интерфейс lo0, который закреплен за петлей 127.0.0.1. Для этого интерфейса также нужна команда ifconfig.

/usr/paul> ifconfig lo0 inet localhost

В данном случае имя localhost будет заменено на 127.0.01.

Но Ethernet - это только один из интерфейсов, которые могут быть использованы при подключении к сети. Кроме него довольно популярны интерфейсы подключения через последовательные порты.

2.8.2 Настройка SLIP

С последовательным портом работают через псевдоустройство sl0, которое и является интерфейсом последовательного порта. Для сцепления sl0 c устройством служит команда slattach: 

/usr/paul/slattach /dev/cuaa0 144.206.160.100 144.206.160.101

Однако, формат slattach от одной системы к другой существенно изменяется. Так в ряде случаев сначала выдается команда slattach, которая присоединяет интерфейс к порту, а затем на нее выдается команда ifconfig для интерфейса sl.

/usr/paul>slattach -c -s 38400 /dev/sio01

/usr/paul>ifconfig sl1 inet 144.206.160.100 144.206.160.101

netmask 255.255.224.0

В данном случае определен интерфейс для обмена данными по протоколу SLIP с компрессией, со скоростью на порту 38400, через порт /dev/sio01.

Как показывает практика, доступ по протоколу SLIP обычно организуют для удаленных пользователей, которые через данный шлюз хотят работать с Internet. Однако, не всегда можно "зацепиться" за модем надежно. Кроме того, на одном и том же порту могут обслуживаться как терминальные пользователи, так и пользователи Internet, а кроме того, туда же можно подключать и пользователей UUCP. В этом случае гораздо разумнее вместо slattach воспользоваться командой sliplogin. Данная команда также имеется не во всех операционных системах. Но обычно во всех есть ее аналог.

Суть sliplogin заключается в том, что пользователь, который дозвонился и работает в режиме удаленного терминала, имеет возможность самостоятельно запустить из этого режима присоединение sl интерфейса и его настройку на IP-адреса и параметры сессии. Это же дает возможность провайдерам, устанавливая стеки TCP/IP на персональных компьютерах, включать в их настройки скрипты, которые автоматически производят аутентификацию в удаленной машине и конфигурирование интерфейса для работы по SLIP.

Выглядит это следующим образом:

· сначала дозваниваются до удаленной машины;

· затем вводят идентификатор и пароль;

· после входа в режим командной строки запускается команда sliplogin;

· после этого следует перейти в режим работы по SLIP.

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

Sliplogin управляется тремя файлами slip.hosts, slip.login и slip.logout. В файле slipl.host перечисляются пользователи, которым разрешено запускать sliplogin, и какие адреса при этом назначаются, а также тип протокола SLIP (с компрессией или без нее). Ниже приведен пример такого файла:

quest:/etc:\[7\]>cat slip.hosts

paul 144.206.192.99 144.206.192.100 255.255.224.0

alex 144.206.130.138 144.206.192.102 255.255.224.0 compress

dimag 144.206.192.99 144.206.192.103 255.255.224.0

dima 144.206.192.99 144.206.192.104 255.255.224.0

vovka 144.206.192.99 144.206.192.105 255.255.224.0

maverick 144.206.192.99 144.206.192.106 255.255.224 0

arch1996 144.206.192.99 144.206.192.107 255.255.224.0

Однако, этого мало. Фактически, sliplogin выполняет slattach на порт, через который работает пользователь, но после этого этот порт надо сконфигурировать. Для этой цели служит скрипт slip.login:

quest:/etc:\[8\]>cat slip.login

#!/bin/sh

/sbin/ifconfig sl$1 $4 $5 netmask $6 >> /tmp/sliplogin.log

exit 0

quest:/etc:\[9\]>

После того, как соединение разорвалось, следует убрать все процессы которые им были вызваны. Для этой цели служит скрипт sliplogout.

quest:/etc:\[9\]>cat slip.logout

#!/bin/sh

PATH=:/bin:/sbin:/usr/bin:/usr/sbin:

export PATH

(ps ax | egrep 'sliplogin | slattach' | grep $3 |grep -v grep | awk '{print $1;}'

| xargs kill ) >> /tmp/sliplogin.log

quest:/etc:\[10\]>

Смысл написанного в этом файле заключается в том, что бы найти все остатки от sliplogin и по команде kill прервать их выполнение.

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

2.8.3 Настройка интерфейса PPP

В различных системах настройка интерфейсов PPP производится по-разному. Поэтому мы снова будем основываться на примере BSDI и FreeBSD. Для работы через PPP в этих системах используется либо демон pppd, либо прикладная программа ppp. Обычно демон используется для выделенных линий и для приема звонков на выделенном под PPP порте. Программа ppp используется для запуска из командной строки.

Для того, чтобы использовать демона в файле конфигурации ядра, необходимо определить псевдоустройство ppp(0-1). Демона помещают в файл начальной загрузки. Настройки демона производятся при помощи файла настроек:

vega-gw: {6} cat options

/dev/cuaa2

57600

194.190.135.22:194.190.135.21

netmask 255.255.255.252

passive

defaultroute

#debug

local

#kdebug 7

В данном примере мы используем файл /etc/ppp/options. В нем определяется порт, через который настраивается интерфейс, скорость на порте, адрес интерфейса и адрес ответного интерфейса провайдера, маска, установленная на сети провайдера, команда passive, которая заставляет оставлять данный интерфейс постоянно в таблице маршрутов, определение его как шлюза по умолчанию, и определяет его управление с локальной машины. Кроме этого, в данном файле есть еще и закомментированные опции, которые использовались автором во время отладки соединения. Включение этих двух опций приводит к полному дампированию пакетов PPP, что позволяет выяснить причины отсутствия соединения или плохого соединения.

В данном случае мы отлаживали соединение с relarn, где на конце relarn пакеты принимал маршрутизатор CISCO.

Если надо устанавливать соединение с удаленной машины со шлюзом, то вместо SLIP можно также использовать PPP. Но только в этом случае лучше всего использовать программу ppp. Она также настраивается через свой файл конфигурации, пример которого приведен ниже:

vega-gw: {7} cat ppp.conf

default:

set device /dev/cuaa0

set speed 38400

disable lqr

deny lqr

# set debug level LCP

relarn:

set ifaddr 194.190.135.22 194.190.135.21

add 0 255.255.255.252 194.190.135.21

Надеюсь, что значение параметров в этом файле понятно и без лишних комментариев.

Главной особенностью программы ppp является то, что ее можно запустить в интерактивном режиме, по мере ее работы менять тип информации, который подлежит отладке.

При использовании и ppp, и pppd команды ifconfig на интерфейсы выдавать не надо, т.к. эти команды сами производят их настройку.

В заключении разговора о настройке интерфейсов приведем пример таблицы интерфейсов с машины, где работает сразу три разных интерфейса:

vega-gw: {9} netstat -ain

Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll

ed1 1500 <Link>00.20.c5.00.35.c4 10574 0 10223 0 2

ed1 1500 194.226.43 194.226.43.1 10574 0 10223 0 2

lp0* 1500 <Link> 0 0 0 0 0

lo0 16384 <Link> 357 0 357 0 0

lo0 16384 127 127.0.0.1 357 0 357 0 0

ppp0 1500 <Link> 58000 0 55347 0 0

ppp0 1500 194.190.135 194.190.135.22 58000 0 55347 0 0

ppp1* 1500 <Link> 0 0 0 0 0

sl0* 552 <Link> 20570 1 21281 0 0

sl0* 552 194.226.43 194.226.43.99 20570 1 21281 0 0

sl1* 552 <Link> 0 0 0 0 0

tun0* 1500 <Link> 0 0 0 0 0



В этой таблице можно найти интерфейс Ethernet (ed1), интерфейс PPP (ppp0) и интерфейс SLIP (sl1), которые находятся в активном состоянии и принимают и отправляют пакеты.

Через интерфейс ed1 (IP-адрес: 144.226.43.1) доступна сеть 144.226.43.0, через интерфейс ppp0 (IP-адрес: 194.190.135.22) доступна сеть 144.190.135.0, которая является путем в Internet, через sl0 (IP-адрес: 194.226.43.99) работает удаленный пользователь.

2.9 Маршрутизация, протоколы динамической маршрутизации, средства управления маршрутами

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

Основывается система маршрутизации на таблице маршрутов, которая определяет куда пакет с данным 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 <команда> <сеть или хост> <шлюз> <метрика>

В поле "команда" указывается команда работы с таблицей маршрутов:

· add - добавить маршрут

· delete - удалить маршрут;

· get - получить информацию о маршруте.

В поле "сеть или хост" указывается адрес отправки пакета.

В поле "шлюз" указывается 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) и < Protocol Gateway>.

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 просматривает при запуске и использует для первоначальной настройки таблицы маршрутов. Содержание этого файла может выглядеть следующим образом:

net 0.0.0.0 gateway 144.206.136.10 netric 1 passive



В данном примере адрес 0.0.0.0 используется для определения адреса умолчания, машина 144.206.136.10 - это шлюз по умолчанию, метрика определяет число hop'ов до этого шлюза, а параметр "passive" - говорит о том, что даже если с этого шлюза никакой информации о маршрутах не приходит, то его все равно не надо удалять из таблицы маршрутов. Последний параметр указывается в том случае, если шлюз только один, если же возможно использование другого шлюза и эти шлюзы активно извещают машины сети о своих таблицах маршрутов, то следует вместо passive использовать active:

net 0.0.0.0 gateway 144.206.136.10 netric 1 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 должна использовать:

#

# Interface shouldn`t be removed from routing table

#

interface 144.206.160.40 passive ;

#

# routing protocol is rip.

#

rip yes;

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

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

# 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;

Однако можно использовать и более сложное описание, основанное на логике работы gated. А логика эта состоит в том , что gated объявляет соседним шлюзам по RIP, что подсеть 144.206.160.0 доступна через интерфейс 144.206.130.137, в свою очередь для подсети gated объявляет, что весь мир доступен через интерфейс 144.206.160.32. Очевидно, что это логика заимствована из архитектуры внешних протоколов маршрутизации и распространена на протоколы внутренние. Это позволяет вести описание маршрутов в едином ключе.

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 ;

} ;

} ;

Первая команда 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.

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 ;

} ;

{ ;

В данном случае все, что 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. Они касаются возможности управлять доступом к машинам локальной сети. Если маршрут доступа к машине или локальной подсети не экспортировать во внешний мир, то о машине или подсети никто и не узнает. Правда в этом случае нельзя использовать эти машины для доступа к внешним ресурсам также.

2.10 Анализ и фильтрация TCP/IP пакетов

В одном из докладов Министерства Обороны США, выполненном по запросу Конгресса, отмечалось, что в последнее время число атак на компьютеры вооруженных сил увеличилось. При этом атакующие, главным образом, используют программы захвата и анализа трафика 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-сообщества еще не было.

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

...